Run an AI Accessibility Acceptance Test Before Launch

Define the exact outcome a user must complete: understand a chart, submit a form, locate information, review generated text, control a voice agent, or receive a visual description. State what the AI may do, what it must never do, and which established accessible or human path remains available.

Include people who use different screen readers, magnification, switch controls, voice control, captions, hearing devices, keyboards, cognitive supports, languages, devices, and connectivity conditions. Compensate participants and involve them before the interface and success metrics are fixed. Compliance expertise does not replace lived experience.

Confirm that setup, consent, prompts, attachments, camera or microphone activation, streaming state, generated output, citations, controls, errors, history, and deletion work by keyboard and assistive technology. Captions need speaker identity and meaningful timing. Audio needs an equivalent text path. Visual descriptions need controllable detail and a way to ask follow-up questions.

Users must be able to tell when the system is listening, recording, viewing, processing, calling a tool, waiting, finished, uncertain, or failed. Do not rely on color, animation, sound, or vision alone. Announce meaningful changes without flooding a screen reader or repeatedly stealing focus.

Seed ambiguous, incomplete, adversarial, and out-of-scope inputs. The product should ask for clarification, expose uncertainty, cite evidence where appropriate, and refuse unsafe high-consequence tasks. Measure confident errors and missed hazards separately from ordinary mistakes. A plausible sentence is not a safe fallback.

Interrupt speech, rotate the device, lose the network, deny a permission, revoke an account, background the app, and cancel midway through a tool action. The user should retain context, understand what completed, reverse consequential changes, and reach a non-AI route. Never make a dangerous workflow depend on the model noticing its own failure.

Make recording and camera state obvious. Test permission revocation, history controls, deletion, retention, sensitive-field redaction, and account switching. Provide a low-data path where practical. Users need a quick way to stop capture when another person, document, screen, or private place enters the frame.

Track task completion, time, assistance required, retries, abandonment, severe errors, user confidence, cognitive load, and recovery success by mode and participant group. Preserve negative results. Pass only when critical tasks work without a mouse or a single sensory channel, severe failures have safe handling, and a named owner accepts the residual risk.

Save the product and model version, device, browser or app, assistive technology, test task, participant context, expected result, actual result, severity, evidence, workaround, owner, due date, retest, and release decision. Re-run the set after model, prompt, interface, tool, or permission changes—not just annual compliance review.