Accessibility bugs are often ordinary product bugs wearing an invisibility cloak. A keyboard user cannot reach the checkout button. A screen reader announces six controls as “button.” An error appears in red but is never announced. At 200% zoom, the navigation eats half the page and the close control wanders off-screen.
AI accessibility testing prompts can help turn verified requirements, design-system rules, and known risks into structured checks. They can propose scenarios, organize coverage, find unanswered questions, and turn sanitized observations into cleaner defect reports. They cannot experience your product as a disabled user, prove conformance, determine legal compliance, or approve a release.
AI can draft a testing map. Humans still have to navigate the product, use real assistive technology, listen to disabled users, and own the result.
Start with an AI test plan when the release strategy is unclear. Use AI test case prompts when requirements need traceable checks. Accessibility testing adds another requirement: successful task completion matters more than a suspiciously green checklist.
Why accessibility testing needs human evidence
Automated scanners are useful. They can catch missing labels, some contrast failures, invalid markup, and other machine-detectable problems. They cannot tell you whether focus order makes sense, whether a label is understandable, whether a workflow is exhausting, or whether a screen-reader announcement arrives at the moment someone needs it.
AI has the same boundary. It can reason over the context you provide, but generated text is not test evidence. If the model says “the modal should trap focus,” that is a hypothesis or requirement—not proof that your modal does it.
Useful accessibility coverage can include:
- keyboard access, visible focus, logical focus order, and escape behavior;
- accessible names, roles, states, values, and screen-reader announcements;
- headings, landmarks, page titles, link purpose, and navigation consistency;
- labels, instructions, validation, errors, status messages, and recovery;
- contrast, non-color cues, forced colors, and meaningful visual states;
- text resizing, browser zoom, reflow, spacing changes, and responsive layouts;
- captions, transcripts, audio description, autoplay, flashing, and motion controls;
- plain language, predictable interaction, time limits, and cognitive load;
- touch target size, orientation, voice input, switch access, and magnification;
- compatibility across the supported browser, operating system, and assistive-technology matrix.
The right coverage depends on the product and its users. A payroll form, streaming player, internal dashboard, and public emergency service do not have the same risk. The model should structure the known context, not invent a universal accessibility program from vibes.
Pair this guide with AI UI testing prompts for broader interface coverage or mobile app testing prompts when platform gestures, native controls, and mobile assistive technologies matter.
The reusable accessibility testing prompt formula
Use this base prompt, then add one specialized template below:
“Act as an accessibility testing planning assistant. I am testing [named user flow] in [product/build] for [user groups] on [approved environment]. Use only the supplied requirements, adopted accessibility standard, supported platform and assistive-technology matrix, component specifications, known risks, and sanitized evidence. Produce [artifact] with setup, actions, expected behavior traced to a source, observable evidence, user impact, cleanup, and unanswered questions. Separate automated checks, manual checks, and disabled-user research. Do not invent execution results, screen-reader output, conformance, legal conclusions, severity, or release decisions.”
Traceability is the anti-theater mechanism. If an expected behavior cannot be tied to an adopted requirement, approved design, component contract, platform convention, or confirmed product decision, label it as a question. Do not let the model quietly upgrade “common practice” into “our product passed.”
Never paste customer PII, credentials, private recordings, production screenshots, support transcripts, health or disability data, unreleased designs, vulnerability details, regulated information, or confidential client material into an unapproved AI tool. Use synthetic accounts, redacted evidence, approved environments, placeholder secrets, and human privacy and security review.
What to collect before prompting
“Check accessibility” produces a generic checklist large enough to wallpaper the office. Give the model a narrow packet of verified, safe context instead.
| Input | Why it matters | Human check |
|---|---|---|
| Named flow and user goal | Defines successful task completion | Product owner confirms scope |
| Build, page, and environment | Anchors evidence to a version | Tester records exact version |
| Adopted requirements | Defines expected behavior | Accessibility owner confirms sources |
| Supported platform matrix | Bounds compatibility work | Confirm browser, OS, and AT versions |
| Component and content specs | Supplies intended semantics | Design and engineering resolve conflicts |
| User states and test data | Exposes validation and recovery paths | Use synthetic, approved accounts |
| Known risks and prior findings | Prioritizes consequential checks | Confirm findings are current |
| Evidence and severity rules | Makes defects reproducible | Humans own impact judgment |
Keep unknowns visible. If nobody has decided how a timeout warning should work with a screen reader, the output should contain a decision request—not an invented requirement in a handsome table.
This came from a book.
Don't Replace Me
200+ pages. 24 chapters. The honest version of what AI means for your career, written by someone who actually builds this stuff.
Get the Book →10 AI accessibility testing prompts
Replace bracketed text with verified, non-sensitive information. These prompts create planning artifacts. They do not execute tests or prove compliance.
1. Turn requirements into a risk-based test matrix
“Using these adopted accessibility requirements, named flows, supported platforms, components, user needs, known defects, and release changes: [paste], create a risk-based accessibility test matrix. Separate automated checks, keyboard checks, screen-reader checks, visual checks, cognitive checks, and research needs. Trace every expected result to a supplied source. Rank by user impact and change risk, and flag missing requirements.”
A useful matrix connects requirements to tasks and evidence. It does not merely repeat guideline numbers. Include who tests, with what setup, on which build, and what observable result counts as evidence.
Prioritize critical tasks such as authentication, purchase, consent, account recovery, document submission, and core navigation. A decorative icon with a weak label and an unreachable payment control are not equivalent just because both appear in the same audit report.
2. Test keyboard navigation and focus behavior
“For this flow, interactive component list, overlays, routes, shortcuts, and focus-management rules: [paste], draft manual keyboard checks. Cover forward and reverse tab order, visible focus, activation, skip links, menus, dialogs, popovers, drag alternatives, escape behavior, route changes, focus restoration, and keyboard traps. Include expected behavior, observed-evidence fields, and stop conditions.”
Run the flow without a mouse or touch input. Confirm every required action is available, focus is visible, and the sequence follows the task rather than the DOM’s archaeological layers.
For dialogs and temporary surfaces, check initial focus, containment where required, escape or close behavior, and return focus. Do not mark the test passed because pressing Tab eventually finds something clickable three browser screens away.
3. Plan screen-reader names, roles, states, and announcements
“Using this semantic component specification, content, state model, and supported screen-reader matrix: [paste], create manual checks for accessible names, roles, values, expanded or selected states, reading order, dynamic updates, loading, errors, confirmations, and route changes. Provide expected meaning, not fabricated spoken output. Flag controls whose purpose depends only on visual context.”
Test with the actual supported screen reader and browser or operating-system pairing. Record versions and interaction mode. Different combinations can expose different behavior, and one successful announcement does not prove universal compatibility.
Names should be concise and useful in context. Ten “Learn more” links or twelve unlabeled icon buttons make a page technically interactive and practically ridiculous. Check that state changes and async updates are announced without hijacking the user’s current position.
4. Check headings, landmarks, links, and page structure
“Given this page outline, navigation model, content hierarchy, and reusable layout: [paste], draft checks for page title, language, headings, landmarks, bypass links, lists, tables, link purpose, current-page indication, and repeated navigation. Compare visual grouping with semantic structure and identify questions where the source is ambiguous.”
Screen-reader users often navigate by headings and landmarks rather than reading every node. A visually polished page with random heading levels can feel like a book whose table of contents was assembled by a raccoon.
Inspect the accessibility tree and then navigate with the assistive technology. Confirm headings describe sections, landmarks are distinct, links make sense in nearby context, and data tables expose meaningful headers. Visual size alone does not create structure.
5. Test forms, instructions, errors, and recovery
“For this form, field inventory, validation rules, required states, help text, submission outcomes, and recovery paths: [paste], create accessibility tests for labels, instructions, autocomplete, required indicators, grouping, input formats, inline validation, error summaries, focus movement, announcements, preserved data, and successful correction. Cite the source for each expected result.”
Test empty submission, malformed values, server errors, expired sessions, and multiple simultaneous errors. Confirm the user can find the problem, understand it, correct it, and submit without re-entering unrelated data.
Color and placeholder text are not labels. A red border is not an explanation. An error summary that moves focus but does not link to fields is only halfway helpful. Human testers should judge whether recovery is understandable, not merely whether an error node exists.
6. Check contrast and non-color communication
“Using these approved colors, component states, themes, backgrounds, charts, icons, and adopted contrast requirements: [paste], create checks for text, large text, controls, focus indicators, disabled and selected states, links, errors, charts, hover, high-contrast or forced-colors mode, and images of text. Separate measurable contrast from human interpretation and flag missing tokens.”
Use approved measurement tools on actual rendered colors. Design-token values may blend with overlays, opacity, antialiasing, images, or state changes. Record the foreground, background, component state, location, and tool result.
Then check meaning. A chart can meet contrast thresholds and still require color vision to distinguish series. An error can have an icon and still be incomprehensible. Non-color cues need to survive the real interaction, not just the static mockup.
7. Test zoom, text resizing, reflow, and spacing
“For this responsive flow, supported viewport range, text components, overlays, sticky regions, and zoom or reflow requirements: [paste], draft checks for browser zoom, text-only resizing, narrow viewport reflow, user text-spacing overrides, orientation, magnification, clipping, overlap, horizontal scrolling, hidden controls, and preserved task completion. Include exact setup and evidence fields.”
Large text and zoom expose fragile assumptions quickly. Check navigation, dialogs, tables, sticky headers, tooltips, toasts, date pickers, and multi-step forms. Content should not vanish under fixed panels or require pixel-perfect scrolling to find the submit button.
Do not shrink the browser and call it equivalent to zoom. Use the specified method and record it. Test the whole task, including errors and confirmation—not only the photogenic default state.
8. Review motion, timing, audio, and video alternatives
“Using these animations, autoplay behavior, timed interactions, flashing content, audio, video, and media requirements: [paste], create checks for pause and stop controls, reduced-motion preference, keyboard access, captions, transcripts, audio description needs, volume control, flashing thresholds, time-limit warnings, extensions, and interruption recovery. Flag decisions requiring specialist or legal review.”
Confirm reduced-motion settings change meaningful animation without hiding information. Check that carousels, moving banners, and auto-updating regions can be paused where required. A tiny pause button that disappears on keyboard focus is performance art, not access.
For media, verify captions and transcripts against the actual content. AI-generated captions can be a starting draft, but names, technical terms, speaker changes, timing, and consequential statements require human review. Never claim a media alternative is accurate because the model produced it confidently.
9. Check cognitive accessibility and plain language
“For this task, audience, content, decision points, memory demands, timeout rules, authentication steps, and support options: [paste], draft a cognitive accessibility review. Check clarity, consistency, chunking, predictable controls, instructions at the point of need, error prevention, confirmation, progress, interruption recovery, and avoidance of unnecessary memory or calculation. Distinguish content suggestions from verified user evidence.”
AI can identify long sentences, unexplained jargon, inconsistent labels, and complicated branching. It cannot decide whether the experience is understandable to every user. Test with representative people, especially when the task is high stakes or the audience has known access needs.
Look for needless memory tests: codes shown on one screen and requested on another, instructions that disappear during entry, arbitrary timeouts, and forms that erase work. Plain language is not childish language. It is accurate language that does not charge users a comprehension tax.
10. Turn observed barriers into actionable bug reports
“Using only these sanitized observations from a completed accessibility test: [paste], draft defect reports with build, environment, platform, assistive technology and version, preconditions, exact steps, observed behavior, verified expected source, user impact, evidence reference, reproducibility, and open questions. Separate observation from interpretation. Do not invent severity, compliance claims, spoken output, or remediation.”
A strong report describes the barrier and the blocked task, not only the markup symptom. “Button has no accessible name” is useful. “Screen-reader user encounters three unlabeled buttons and cannot identify which one submits payment” explains the consequence.
Humans should confirm reproduction, severity, ownership, and the fix. Suggested remediation may affect component architecture, content, design, security, or workflow. Treat generated code as a candidate for review, then rerun the original task with real assistive technology.
For general defect structure, use these AI bug report prompts. For release-level coverage, add an AI QA checklist without pretending the checklist replaces testing.
A practical workflow that avoids compliance theater
- Name the task. “Accessibility test the site” is not a task. “Create an account, recover a password, and confirm the dashboard with keyboard and supported screen reader” is.
- Confirm the sources. Gather adopted requirements, component contracts, supported platforms, and current designs.
- Remove sensitive material. Use synthetic users and redact evidence before prompting.
- Generate a draft matrix. Require traceability, unknowns, and separate automated from manual checks.
- Review before execution. Accessibility, design, engineering, QA, content, privacy, and security owners correct the plan.
- Execute on the named build. Record actual tools, versions, steps, observations, and evidence.
- Report barriers by impact. Explain the blocked or degraded user task without inventing legal conclusions.
- Fix and retest. Verify the original path and nearby component instances. A patched selector is not the same as a usable experience.
- Include disabled users. Expert testing and user research answer different questions; mature teams need both.
This workflow matches the broader rule in the no-BS guide to using AI at work: give AI bounded work, verify the output, and keep accountability attached to a human.
Common ways this goes wrong
Treating generated checks as evidence
A test case is a plan. A model’s prediction is not an observation. Only executed checks on the identified build produce evidence.
Claiming conformance from an automated scan
Automation catches a valuable subset of issues. A zero-error report does not prove keyboard usability, useful semantics, understandable content, or successful task completion.
Testing one assistive-technology combination
Support policies should define the matrix. Record versions and results. Do not generalize one browser and screen-reader pairing to every platform.
Inventing severity from a guideline reference
Severity depends on blocked tasks, affected users, frequency, workarounds, risk, and product context. Let the model organize evidence; let accountable humans judge impact.
Pasting sensitive user evidence into public tools
Accessibility research can include disability information, voices, faces, account details, and deeply personal context. Follow consent, retention, access, privacy, security, and vendor rules. “We removed the email address” may not be enough to de-identify a story.
Replacing disabled-user research with personas
Generated personas cannot report fatigue, confusion, trust, dignity, or coping strategies. Use them, at most, to brainstorm questions—not as fake participants.
If your team is still fuzzy on the boundary, read what AI can and cannot do. Fast pattern generation is useful. It is not lived experience or accountability.
Frequently asked questions
Can AI perform accessibility testing automatically?
It can support automated tools, organize findings, suggest checks, and draft scripts. Unless it is explicitly connected to approved tools, it has not inspected your product at all. Even connected automation covers only part of accessibility. Manual task testing and disabled-user research remain necessary.
Can these prompts prove WCAG conformance?
No. They can help map adopted requirements to planned checks and organize verified evidence. Conformance evaluation requires appropriate expertise, scope, methods, representative pages or flows, manual testing, and accountable review. Legal obligations vary, so involve qualified accessibility and legal specialists where needed.
Which screen reader should we test?
Use the combinations in your documented support policy, informed by product platforms and users. Record the screen reader, browser or operating system, versions, settings, and interaction mode. Do not choose one pairing because it happens to be installed on a developer’s laptop and declare victory.
Should AI write accessibility fixes?
It can draft candidate markup, tests, labels, or remediation notes. Humans must review semantics, component behavior, content meaning, compatibility, security, and regressions. Retest the complete user task with the relevant assistive technology after the change.
How should we prioritize accessibility defects?
Consider whether the barrier blocks or degrades a critical task, who is affected, how often it occurs, whether a reasonable workaround exists, and the product’s risk. Guideline mapping helps trace requirements but should not replace user-impact judgment.
Is an automated accessibility score useful?
As a trend signal, sometimes. As proof of usability or conformance, no. Scores can hide severe manual issues and can encourage teams to optimize what the scanner sees instead of what users need. Keep the underlying findings and task evidence visible.
Can AI replace accessibility specialists or disabled-user research?
No. AI is useful for formatting, variation, traceability, and gap spotting. Specialists contribute testing judgment and remediation expertise. Disabled users contribute lived experience and reveal barriers, strategies, and priorities that synthetic personas cannot supply.
What information is safe to paste into an AI tool?
Use only data approved by your organization and vendor policy. Prefer synthetic accounts, placeholder content, redacted screenshots, sanitized markup, and generalized observations. Exclude credentials, customer PII, disability or health data, private recordings, unreleased product details, vulnerabilities, and regulated or confidential information unless an explicitly approved environment and process permits it.
The point is better testing, not fewer humans
AI accessibility testing prompts are valuable because accessibility work contains plenty of structure: matrices, requirement mapping, state combinations, evidence fields, and repeatable report formats. Let the machine accelerate that structure.
Keep the human work human: operating real interfaces, using assistive technology, listening to disabled people, interpreting impact, deciding remediation, protecting sensitive evidence, and owning the release.
That is the practical thesis behind Don’t Replace Me by Dmitry Kargaev: use AI for speed without confusing speed for judgment. The goal is not a prettier compliance document. It is a product more people can actually use.
