Test the candidate journey, scoring behavior and a workable alternative before an AI recruitment tool reaches applicants.

An accessibility check for an AI recruitment tool has two separate jobs:

1. Can a candidate complete the process? Test the interface with keyboards, screen readers, magnification, voice input and other relevant assistive technology.
2. Does the tool measure the job requirement rather than effects of a disability? Inspect what the system observes, infers and scores.

A technically accessible assessment can still penalize a speech impairment, atypical eye movement or slower interaction. Conversely, a job-relevant assessment is not usable if an applicant cannot navigate it. Employers need to test both before deployment.

This is a US-focused workflow, current September 27, 2026. It is informational, not legal or employment advice. ADA coverage depends on the employer and circumstances, while state and local requirements may add obligations.

1. Map the complete candidate journey

Do not test only the vendor’s demonstration page. Create a staging vacancy and follow every route a real candidate encounters:

• job advertisement and application form;
• account creation, identity checks and login recovery;
• instructions and practice questions;
• résumé upload or parsing;
• chatbot, game, test or recorded interview;
• notices and the accommodation-request route;
• submission confirmation and status messages.

Record every component, including third-party video, scheduling, proctoring and identity-verification services. Assign an owner to each barrier rather than assuming the principal vendor controls the whole journey. Using another company’s technology does not remove an employer’s responsibility to avoid disability discrimination, according to the US Department of Justice’s hiring-technology guidance.

For each stage, document the input collected and the decision it affects: knockout, score, rank, recommendation or recruiter display. That map reveals where an inaccessible interaction can become a rejection.

2. Define what each scored feature is supposed to measure

Write down the job-related construct before looking at model output. If a timed game claims to assess attention, for example, ask whether response speed is essential to this job or merely part of the interface. For a video tool, identify whether it scores the transcript, word choice, audio delivery, facial signals or some combination.

DOJ says covered employers must ensure that tests measure relevant skills and abilities rather than impaired sensory, manual or speaking skills that the test is not intended to measure. It also advises employers to examine hiring technologies before use and regularly afterward for disability-related screening out (DOJ guidance).

Create a feature register with four fields:

Field	Question to answer
Job requirement	What essential function or qualification does this feature represent?
Observed signal	What does the software capture: text, timing, clicks, voice or video?
Score effect	How does that signal alter a score, rank or recommendation?
Disability risk	Could disability or assistive technology change the signal without changing the person’s ability to do the job?

“Proprietary model” is not an adequate answer to the last three questions. If the employer cannot determine what an assessment measures or how an alternative will be scored, it cannot perform a meaningful predeployment review.

3. Test technical access with people, not only a scanner

Set a documented technical target such as WCAG 2.2 AA where appropriate, while checking which standard and law apply to the employer and product. WCAG addresses web content, including dynamic content, multimedia, web interfaces on mobile and AI web interfaces; W3C separately explains how it can be applied to non-web software through WCAG2ICT. W3C encourages use of its latest published WCAG version (WCAG overview). WCAG is a technical standard, not by itself a declaration that an employer has met every ADA obligation.

Run automated checks, expert manual review and task-based user testing. W3C cautions that no tool alone can determine whether a site meets accessibility standards; knowledgeable human evaluation is required (evaluation guidance).

As applicable to the product, complete the journey while checking:

• keyboard-only operation, visible focus and logical focus order;
• screen-reader names, instructions, state changes and error messages;
• text resizing, zoom, reflow, contrast and non-color cues;
• form labels, required fields and recovery from validation errors;
• captions, transcripts and controls for audio or video;
• compatibility with voice input and relevant assistive-technology/browser combinations;
• time limits, warnings, pause and extension controls;
• flashing, motion and interactions requiring precise dragging or gestures;
• save-and-return behavior and recovery after a connection failure.

Include disabled users who use relevant assistive technologies, compensate them, and give them realistic tasks rather than asking whether pages “look accessible.” User testing can expose problems that conformance checks miss, but one person cannot represent every disability. W3C recommends combining users with standards-based evaluation and clearly reporting the test scope (user-evaluation guidance).

4. Check whether the access method changes the result

Interface conformance does not test the model. Use controlled comparisons in which the job-relevant substance stays constant while the access method changes. Depending on the tool, compare:

• a spoken response with an accurate transcript or written response;
• standard time with an approved extended-time setting;
• mouse input with keyboard or switch input;
• a video response with an alternative that preserves the relevant content;
• a vendor-generated transcript with a corrected transcript.

Inspect the raw capture, extracted features, score, recommendation and recruiter-facing output—not only whether submission succeeded. Investigate differences rather than setting a universal “acceptable” score gap. The questions are whether the changed signal is job-related and whether the comparison itself is valid.

These controlled checks are diagnostic tests, not substitutes for evaluation with disabled users. Cover plausible barriers involving visual, hearing, speech, mobility, cognitive and neurological disabilities. Use recruited testers and synthetic scenarios for prelaunch work rather than turning live applicants into the test pool. Keep disability-related information obtained through accommodation requests confidential and limited to people who need to know, consistent with Department of Labor employer guidance.

5. Build a workable alternative before launch

“Contact support” is not an effective alternative unless somebody can respond before the deadline and the replacement process is ready. Define:

• an accessible request channel that does not require using the inaccessible tool;
• the HR owner and response target;
• who may receive disability-related information;
• available adjustments and alternative assessment formats;
• how recruiters prevent an accommodation request from reducing candidacy;
• how results from different routes will be evaluated consistently.

An alternative should assess the relevant capability without introducing a harder test or diverting candidates into an unrelated, unstructured interview. Extra time is not a universal fix: it does not correct unreliable speech transcription or an inaccessible drag-and-drop task.

The EEOC’s AI and ADA resource page collects its employer and worker materials. DOJ advises employers to tell applicants what technology is used, explain how they will be evaluated, provide enough information to decide whether an accommodation may be needed, and maintain a clear request procedure that does not harm candidacy (DOJ guidance).

Give candidates a plain-language request route. The companion candidate accommodation guide explains what applicants may need to specify.

6. Make accessibility a launch gate

Before approval, require an evidence pack containing:

• tested product, model and configuration versions;
• browsers, devices and assistive technologies covered;
• tasks, standards, testers and dates;
• defects, severity, owners and remediation dates;
• scored-feature and job-relevance analysis;
• controlled-comparison results and unresolved discrepancies;
• the operational alternative and a completed dry run;
• candidate notice and accommodation procedure;
• vendor commitments for updates, defect notification and retesting.

A vendor accessibility statement or conformance report is useful input, not proof that the employer’s configured hiring flow or scoring logic works. Add the evidence to the broader AI hiring vendor validation checklist.

Do not launch a required route when a candidate cannot complete a step, a disability-sensitive signal affects selection without a defensible job-related basis, or the alternative exists only on paper. For a lower-severity defect, document the interim control, owner and deadline.

Retest after model, interface, proctoring or integration changes. After deployment, review accommodation requests, failure patterns and selection outcomes. A prelaunch pass is a version-specific finding, not a permanent property of the product; use a defined post-deployment monitoring plan to decide when to investigate, pause or withdraw the tool.