Deque’s 2024 coverage study (13,000+ pages, ~300,000 issues) found that fully automated tooling like axe-core catches about 57% of WCAG issues — and the remaining ~43% is exactly the part that breaks real users: focus traps, missing live regions, broken keyboard order, and motion that triggers seizures. None of that shows up as a red line in CI. The prompts below hand the failure mode to an LLM (Claude Opus 4.7 or GPT-5.5 read diffs and component code well) and force reproduction steps, file:line references, and a fix — not a vague “consider improving accessibility.”
TL;DR
- Run axe-core first. It clears the ~57% of issues a machine can verify with near-zero false positives. Don’t burn AI tokens re-finding contrast bugs.
- Use these 12 prompts for the other ~43%: keyboard tab order, focus management on route change, screen-reader announcements, WCAG 2.2 target size, and
prefers-reduced-motion. - Target WCAG 2.2 Level AA. It is the current stable W3C recommendation (published October 2023) and adds six AA criteria most teams miss, including Target Size (Minimum) at 24×24 CSS px and Focus Not Obscured.
- Compliance is now enforced. The European Accessibility Act deadline passed June 28, 2025; its presumed standard (EN 301 549) maps to WCAG 2.1 AA, with penalties up to €100,000 or 4% of revenue.
Who this is for
Engineers shipping consumer apps that must meet WCAG 2.2 AA, designers running a11y reviews, and founders bidding on government or enterprise contracts that require a documented audit. If you sell into the EU after June 2025, accessibility is a legal requirement, not a nice-to-have.
What WCAG 2.2 added that axe-core can’t fully check
WCAG 2.2 (the current W3C recommendation) introduced nine new success criteria; six of them land at Level AA, the tier most organizations target. Three matter most for regression audits and are awkward to test automatically:
| Criterion | Level | The rule | Why a tool struggles |
|---|---|---|---|
| 2.4.11 Focus Not Obscured (Min) | AA | A focused element can’t be fully hidden by author content | Needs to know if a sticky header/cookie banner overlaps the focus ring at runtime |
| 2.5.7 Dragging Movements | AA | Any drag action needs a single-pointer alternative | Tool can’t tell intent behind a drag handle |
| 2.5.8 Target Size (Min) | AA | Targets ≥ 24×24 CSS px or sufficiently spaced | Padding, inline exceptions, and spacing math are easy to miscount |
Note the number: WCAG 2.2 sets the floor at 24×24 CSS px, not 44. The 44×44 figure is Apple’s Human Interface Guidelines recommendation, and Material Design suggests 48×48 dp — both are good design targets above the legal minimum.
12 copy-ready prompt templates
Paste your diff or component code under each prompt. Each one names a specific failure mode and demands file:line plus severity so output is actionable, not advisory.
1. PR-scoped a11y diff
Audit this PR for a11y regressions in the diff only. Cover: (1) New interactive elements without keyboard handlers, (2) `role="button"` on non-buttons missing key handlers, (3) Removed aria-labels, (4) Decorative imagery added without `alt=""`, (5) Heading order broken. Output file:line + severity (blocker/major/minor). Skip unchanged code.2. Keyboard order verification
For `[componentName]`, describe the keyboard tab order step by step (Tab / Shift+Tab / Enter / Esc / Arrow keys). Flag: (1) Focus skipping a logical element, (2) Focus moving into invisible content, (3) Tab order that doesn't match visual order, (4) Esc that doesn't close a modal, (5) Focus not returned to the trigger on close.Variables to swap: [componentName]
3. Screen-reader copy review
Audit what a screen reader (NVDA/VoiceOver) will announce for `[componentName]`: (1) Accessible name (label / aria-label / aria-labelledby), (2) State announcements (selected / expanded / loading), (3) Live region for async results, (4) Icon-only buttons get a visible-or-aria name. Output a script-like trace of expected announcements per interaction.Variables to swap: [componentName]
4. Form error accessibility
Audit this form's error UX: (1) Errors associated via `aria-describedby` to the right input, (2) Submission summary at top with anchor links, (3) Live region announces error count, (4) Focus moves to first invalid field on submit, (5) Errors don't rely on colour alone. Output file:line.5. Focus management on route change
For this SPA, audit focus management on navigation: (1) Does focus move to the new page's main heading? (2) Is the page title announced? (3) Are skip-links present and working? (4) Does focus survive modal open/close? Output failures + a fix recipe per page.6. Focus Not Obscured (WCAG 2.2, 2.4.11)
Audit WCAG 2.2 SC 2.4.11 Focus Not Obscured (Minimum). Identify any sticky header, cookie banner, chat widget, or toast that can fully cover a focused element when tabbing. For each: name the overlapping component, the elements it can hide, and a scroll-padding or focus-scroll fix. file:line.7. Motion + prefers-reduced-motion
Audit motion: (1) Any animation > 5s that loops without pause/stop? (2) Flashing > 3 times per second (seizure risk, WCAG 2.3.1)? (3) Parallax or autoplay video without controls? (4) Is `prefers-reduced-motion` honoured for every transition/animation? Output file:line + fix.8. Colour contrast on the diff
For colour changes in this diff only, compute contrast against WCAG 2.2 AA: (1) Body text ≥ 4.5:1, (2) Large text (≥ 18.66px bold or 24px) and UI components ≥ 3:1, (3) Focus indicator ≥ 3:1 against adjacent colours. Give the measured ratio per pair. Don't check unchanged elements.9. Target size (WCAG 2.2, 2.5.8)
Audit interactive targets against WCAG 2.2 SC 2.5.8 Target Size (Minimum): each target ≥ 24×24 CSS px including padding, OR a 24px-diameter circle around it doesn't overlap another target. Note inline-link and user-agent exceptions. Also flag anything below 44×44 (Apple HIG) as a design improvement, not a failure. file:line + severity.10. Loading / async announcement
Audit async UX: (1) Loading state announced via aria-live or role="status", (2) Errors announced via aria-live="assertive" sparingly, (3) Optimistic UI matched by a reverted, announced state on failure. Output file:line.11. Custom widget ARIA pattern
For `[widgetType]`, verify it implements the WAI-ARIA Authoring Practices pattern. List: (1) Required role + key behaviours, (2) Where this implementation diverges, (3) Top 3 fixes ranked by user impact. Don't propose a full rewrite if 2 patches close the gap.Variables to swap: [widgetType] — combobox / tabs / dialog / menu / treegrid
12. Mobile screen-reader walkthrough
Walk through this screen with VoiceOver (iOS) and TalkBack (Android). Predict the announcement per swipe-right. Flag where Android and iOS diverge meaningfully (e.g. heading nav, custom roles). Output a comparison table.Bonus: a11y regression triage
Last release had [nIssues] a11y bug reports. Triage: (1) Cluster by component, (2) Identify the top 3 by user impact (severity × reach), (3) Suggest one preventive check per cluster (axe rule, lint rule, or manual step). Output a table.Variables to swap: [nIssues]
Common mistakes
- Treating “no axe violations” as a pass. Automated tooling covers ~57% of issues; the rest needs keyboard and screen-reader checks.
- Removing focus rings for visual polish. This kills keyboard usability and breaks WCAG 2.4.7.
- Using
<div onClick>instead of<button>. You lose keyboard activation and the screen-reader role in one move. - Tab traps in modals because focus isn’t returned to the trigger on close.
aria-live="assertive"on every update. It interrupts and overwhelms screen-reader users; reserve it for genuine alerts.- Form errors marked only in red. Invisible to colour-blind users; pair colour with text and an icon.
- Skipping the WCAG 2.2 additions — target size, dragging alternatives, and focus-not-obscured are the most common new gaps.
How to push results further
- Run axe-core (or Axe DevTools) in CI first, then use these prompts for what it misses.
- Test keyboard-only navigation manually on every new interactive component.
- Inspect with VoiceOver / NVDA at least quarterly, and on any flow that handles money or auth.
- Use semantic HTML; ARIA is the fallback, not the goal — a real
<button>beatsrole="button"every time. - Add a one-page
a11y.mdper component documenting its keyboard and screen-reader contract. - Block PRs that introduce new axe-core violations; don’t block on pre-existing ones, to keep PR scope tight.
FAQ
- Is axe-core enough for WCAG AA?: No. Deque’s data puts automated coverage at ~57% of issues. Combine it with manual keyboard and screen-reader checks for the rest.
- What WCAG version should I target in 2026?: WCAG 2.2 AA — it’s the current W3C recommendation (October 2023). Note the EU’s EAA still maps to WCAG 2.1 AA via EN 301 549, but 2.2 is a superset, so targeting 2.2 covers both.
- Is 44×44 the legal minimum target size?: No. WCAG 2.2 SC 2.5.8 sets the floor at 24×24 CSS px. 44×44 is Apple’s recommendation and 48dp is Material Design’s — good targets, not the legal bar.
- Do I really need a disabled tester?: For any consumer-scale product, eventually yes. Tooling plus AI gets you to “good”; lived-experience testing gets you to “great.”
- What’s a 30-second smoke test?: Unplug your mouse and complete the feature with the keyboard only. If you can’t, neither can a keyboard user.
- Can AI replace an a11y consultant?: Not for high-stakes or legal audits. Use AI for routine, PR-scoped checks; bring in a consultant for edge cases and sign-off. See the W3C’s WCAG 2.2 standard and WAI-ARIA Authoring Practices for the source of truth.