Most accessibility audits stop the moment axe-core turns green. The problem: automated tooling catches only about 57% of real-world accessibility issues by volume (Deque’s 2024 study across 13,000+ page states), and that share is inflated by high-frequency color-contrast errors. The failures that actually trip users — focus traps in custom widgets, modal stacks that lose focus on close, live regions that read decorative spam, color-only error states, 23×23px tap targets that miss WCAG 2.2’s new 24px floor — are exactly the ones automation can’t see.
These 12 prompts force an AI model to walk the page twice (once as a keyboard-only user, once as a screen-reader user) and to map every finding to a specific WCAG 2.2 success criterion with a one-line fix. WCAG 2.2 (published October 2023, updated December 2024, now ISO/IEC 40500:2025) is the de facto standard as of June 2026 — WCAG 3.0 is still a Working Draft and is not expected to reach Recommendation before 2028. Pair these with the accessibility regression audit prompts to lock fixes in before they drift back next release.
TL;DR
- Run axe-core or Lighthouse first to clear the cheap 57%, then use prompts 1-12 to hunt the manual half.
- Every prompt ends by mapping findings to a named WCAG 2.2 criterion plus a one-line fix and a manual re-test step.
- Paste real HTML or component source — generic descriptions produce generic, unverifiable answers.
- Best model: Claude Opus 4.7 or Sonnet 4.6 (1M-token context handles whole components), GPT-5.5, or Gemini 3.1 Pro. Any of the three reasons well about ARIA patterns; verify ARIA roles against the spec, not the model’s memory.
- These prompts audit; they do not certify. Legal sign-off (EAA, ADA) still needs a human accessibility tester.
Best for
- Pre-launch accessibility audits
- WCAG 2.1 / 2.2 AA compliance reviews (the level the EU’s European Accessibility Act expects via EN 301 549)
- Custom-component accessibility reviews
- Form-flow accessibility
- PR-level accessibility checks
How to use these prompts
Paste the prompt, then paste the actual HTML, JSX, or rendered DOM directly underneath where it says [paste ...]. The model can only audit what it can see — a description like “a dropdown menu” produces a textbook answer, while the real markup surfaces the missing aria-expanded and the <div onClick> that should be a <button>. For dynamic widgets, paste the component source plus a short note on what state changes happen (open/close, error, loading), because screen-reader and live-region behavior depends on runtime state the static markup doesn’t show.
1. Semantic-HTML audit
Below is page or component HTML. Audit semantic HTML usage:
(a) heading hierarchy (no skipped levels, one h1),
(b) landmarks (header / main / nav / footer / aside),
(c) lists vs div soup,
(d) buttons vs links vs divs (action = button, navigation = link).
For each issue give the WCAG 2.2 criterion and a one-line fix.
[paste HTML]2. Keyboard-navigation walkthrough
Below is a page or component. Walk through it as a keyboard-only user.
Tab through every interactive element and list:
(a) tab order vs visual order,
(b) focus visibility (per 2.4.7 and the 2.4.13 focus-appearance size/contrast guidance),
(c) keyboard traps (2.1.2),
(d) skip-link presence (2.4.1),
(e) any control reachable only by mouse.
Flag every break with its WCAG criterion.
[paste]3. Screen-reader flow audit
Below is a page. Describe what a screen-reader user (assume NVDA or VoiceOver)
would hear from page load through completing the main task. Flag every place where:
(a) decorative content is announced,
(b) meaningful content is missed,
(c) a state change is not announced.
Note the accessible name source (label / aria-label / aria-labelledby) for each control.
[paste]4. Color-contrast checker
Below is my color palette plus 10 sample component combinations (text on background).
For each, output: contrast ratio, WCAG AA verdict (4.5:1 normal text, 3:1 large text
and UI components per 1.4.11), AAA verdict (7:1), and the smallest hex adjustment that passes AA.
[paste colors]5. Form a11y audit
Below is my form. Audit:
(a) label association (for/id or wrapping label),
(b) error-message announcement (aria-describedby + role=alert),
(c) required-field indication (not color alone),
(d) keyboard submit,
(e) focus management on error (move focus to first invalid field),
(f) autocomplete attributes (1.3.5),
(g) accessible authentication: no cognitive-test step like solving a puzzle (3.3.8).
Map each issue to a WCAG 2.2 criterion.
[paste form HTML]6. Modal / dialog a11y
Below is my modal component. Audit:
(a) focus moves into the modal on open,
(b) focus trap stays inside while open,
(c) Esc closes,
(d) role=dialog + aria-modal=true + aria-labelledby,
(e) focus returns to the trigger on close,
(f) background scroll prevention,
(g) the dialog is not obscured when focused (2.4.11).
Flag each break with its criterion.
[paste]7. Custom-widget ARIA review
Below is a custom widget (tabs / accordion / combobox / menu / etc.).
Compare it against the matching WAI-ARIA Authoring Practices (APG) pattern.
List deviations and propose the minimum ARIA roles, states, and keyboard handlers
(arrow keys, Home/End, Enter/Space) needed to comply. Verify each ARIA role
against the spec, not from memory.
[paste]8. Image alt-text audit
Below are 10 images on a page with their current alt text. For each:
(a) is the image decorative (alt="") or informational,
(b) does the alt text serve the image's function in context,
(c) is it redundant with adjacent text,
(d) for complex images (charts/diagrams), is there a longer description nearby.
Propose corrected alt text (1.1.1).
[paste]9. Focus-management audit
Below is a multi-step flow. Walk through focus behavior at each transition:
(a) where focus starts,
(b) where it moves on next/back/submit,
(c) what is announced.
Flag any transition that drops focus to the top of the document or to body,
and check that focus is never entirely hidden behind sticky headers (2.4.11).
[paste]10. Dynamic-content live-region audit
Below is a component that updates dynamically (toast / search results / form errors).
Audit:
(a) is the update announced,
(b) is the live-region politeness right (aria-live=polite for status,
assertive only for errors/urgent),
(c) is it announced too often or stealing focus,
(d) is the region in the DOM before the update (empty live regions added late often don't fire).
[paste]11. Color-only-signal finder
Below is a page or chart. Find every place where information is conveyed by color alone
(e.g., red = error with no icon or text, green/red status dots, chart series by hue only).
For each, propose a non-color secondary signal (icon, text label, pattern). Map to 1.4.1.
[paste]12. WCAG criterion mapping
Below is my axe-core or Lighthouse accessibility report. For each issue:
(a) map to the specific WCAG 2.1 / 2.2 criterion and level (A / AA),
(b) priority (blocker / major / minor),
(c) the minimum code fix,
(d) the manual test that verifies it (keyboard, screen reader, or contrast tool).
Add a short list of likely WCAG failures axe-core does NOT detect on this kind of page.
[paste report]What WCAG 2.2 added that audits still miss
WCAG 2.2 introduced nine new success criteria in 2023; four of them routinely slip past older audit checklists, so name them explicitly when you run prompts 2, 6, and 9:
| Criterion | Level | What it requires |
|---|---|---|
| 2.4.11 Focus Not Obscured (Minimum) | AA | A focused element must not be fully hidden by sticky headers, footers, or other author content |
| 2.4.13 Focus Appearance | AAA | Focus indicator min 3:1 contrast against unfocused state and a minimum size |
| 2.5.7 Dragging Movements | AA | Any drag interaction needs a single-pointer alternative (tap/click) |
| 2.5.8 Target Size (Minimum) | AA | Touch targets at least 24×24 CSS pixels (with spacing exceptions) |
Common mistakes
- Treating axe-core green as “audit done.” Automation catches roughly 57% of issues by volume and far less by criteria count; the keyboard and screen-reader walkthroughs are where the rest live.
- Skipping the keyboard-only walkthrough, so focus traps and missing skip-links never get found.
- Building custom tabs / combobox / menu widgets without checking against the WAI-ARIA Authoring Practices (APG) pattern.
- Error or success states conveyed by color alone — fine for sighted users, invisible to color-blind and screen-reader users.
- A modal that traps screen-reader focus but not keyboard focus (or vice versa) — both have to be tested independently.
- Live regions that announce decorative updates, training users to ignore the assertive channel.
- Ignoring WCAG 2.2’s 24px target-size and focus-not-obscured criteria because the audit template predates them.
- Trusting an AI’s ARIA roles from memory. Models hallucinate role names and state combinations; cross-check against the W3C ARIA Authoring Practices Guide.
FAQ
Can these prompts replace a manual accessibility audit? No. They replace the tedious first pass and catch a large share of the manual-only issues automation misses, but legal compliance — the EU’s European Accessibility Act (in force since 28 June 2025), the ADA — still needs a human tester using a real screen reader. Treat the AI output as a prioritized to-do list, not a certificate.
Which model works best for accessibility audits? Claude Opus 4.7 and Sonnet 4.6 (1M-token context as of June 2026) comfortably hold a whole component plus its CSS, which matters for contrast and focus reasoning. GPT-5.5 and Gemini 3.1 Pro both reason well about ARIA patterns too. The differentiator is context size and your willingness to paste real markup, not raw model IQ.
Why map to WCAG 2.2 and not WCAG 3.0? WCAG 3.0 is still a Working Draft (the March 2026 draft lists 174 requirements and drops pass/fail grading) and is not expected to be a W3C Recommendation before 2028. WCAG 2.2 AA is what regulators and EN 301 549 reference today, so it is the standard your audit should map against in 2026.
Should I run axe-core or Lighthouse before these prompts? Yes. Let automation clear color contrast, missing alt attributes, and form labels — the high-volume, machine-detectable issues — then feed the report into prompt 12 and spend your manual time on keyboard, screen-reader, and widget behavior.
How do I verify the AI’s ARIA suggestions are correct? Cross-check every proposed role and state against the W3C ARIA Authoring Practices Guide, then test with a real screen reader (NVDA on Windows, VoiceOver on macOS/iOS). AI models occasionally invent role/state combinations that do not exist or that browsers ignore.
Related
- React component refactor prompts
- Performance optimization prompts
- Code review prompts
- Bug audit prompts
- SEO audit prompts
- Accessibility Regression Audit Prompts: 12 Templates Beyond axe-core
- TypeScript Error Diagnosis Prompts for Cryptic TS Errors
- Migration Plan Prompts: 12 Templates for Framework / DB / Auth Moves
Tags: #Prompt #AI coding #AI coding