Where Surhires stands on accessibility, stated honestly

A recruiter blocked by an interface problem has a colleague, a phone, a workaround and an employment relationship with the firm that bought the software. A candidate blocked by an inaccessible application form has none of those. They have one route into the opportunity, and if it does not work they are simply not in the process. Nobody records that as a failure, because the person never appears in the funnel at all.

So the priority order is deliberate: the career portal and application flow, the candidate self-service and consent screens, interview scheduling and self-scheduling, then the recruiter-facing application, then internal administrative surfaces. That order is not about who matters more. It is about who has an alternative and who does not.

It also happens to be the order in which failures are most likely to matter legally to the firms using the product, because the candidate-facing surface is the one their applicants meet and the one their clients ask about.

Testing runs on three tracks because no single track catches enough. Automated checks run in the build against every candidate-facing route and fail the build on regressions in colour contrast, missing form labels, missing alternative text and landmark structure. Automated tooling catches a minority of real barriers and is treated as a floor rather than a result.

Manual keyboard testing covers every candidate-facing flow end to end: reaching every control by keyboard, visible focus at all times, no keyboard traps, a working skip link, and modal focus management that returns you where you started. Screen reader passes cover the same flows on the combinations most likely to be in use.

Content and design review covers the things tooling cannot judge: whether an error message says what to do rather than that something is wrong, whether a label describes its field, whether an instruction depends on colour or position alone, and whether a timeout gives a person enough time to complete a form that asks about their working life.

Every product of this size has open findings, and the useful question is whether they are visible. Current findings are published with the surface affected, the success criterion involved, the severity, the workaround where one exists, and the status. Items that are being fixed say so. Items that are not being fixed soon say that too, with the reason.

Some categories are genuinely harder and pretending otherwise helps nobody. Complex data tables with many columns, drag-and-drop pipeline interactions, richly interactive charts and third-party embedded components all need alternative routes rather than a claim that the primary interaction is fine. Where an alternative route exists, it is documented next to the finding.

Uploaded content is the limitation with the widest reach. A resume, a job description or a client document uploaded into the system carries whatever accessibility its author gave it. The product can present it accessibly and extract text where the file allows, but it cannot repair a scanned image of a document that contains no text layer.

Barriers can be reported directly to Soor LLC by email to the support address, or by phone during support hours, Monday to Friday, 8am to 8pm ET. A report is more useful with the page or screen, what you were trying to do, the assistive technology and browser in use, and what happened instead, but an incomplete report is still worth sending and will not be turned away for missing fields.

The commitment is an acknowledgement from a person rather than an automated receipt, a substantive response describing what was found and what will happen, and where a fix will take time, a workaround in the meantime. Reports that identify a genuine barrier on a candidate-facing surface are treated as defects rather than as feature requests, which is the difference that decides whether anything gets fixed.

Where the barrier is on a career portal operated by a customer firm using their own branding and their own content, the report is routed to that firm, because the content and configuration are theirs. That routing is prompt, and the underlying platform issue, if there is one, is still ours.

Software is one part of an accessible hiring process. The rest sits with the firm running it: whether job descriptions are written clearly, whether an assessment has an accessible alternative, whether a candidate can request an adjustment and be met without being disadvantaged, and whether the people conducting interviews know how to handle a request when it arrives.

The product supports the parts it can. Application forms are built to the standard, candidates can request an adjustment as part of the flow, that request is recorded on the record and surfaced to the recruiter rather than sitting in an inbox, and scheduling can accommodate extra time as a property of the interview rather than as a note somebody has to remember.

What it cannot do is make a hiring decision fair, or make an inaccessible third-party assessment accessible, or supply the judgement to grant an adjustment. Those are yours. Naming them is more useful than a statement of commitment that leaves the reader unsure who has to act.