Accessibility review workflow
Review a component or page against WCAG 2.2 AA with automated checks, an AI code review and a short manual keyboard and screen-reader pass.
Fill in your details
Values are inserted into every prompt below. Nothing you type leaves your browser.
2 field(s) left — unfilled variables stay as {{placeholders}}.
1Run automated checks
Run an automated checker such as axe (browser extension or in your tests) or Lighthouse's accessibility audit. Automated tools catch only a portion of issues — often estimated at around a third — so this is a starting point.
2AI code review
Paste the component or let your agent read it. Ask for WCAG success-criterion references so you can look each one up.
Review this UI code for accessibility against WCAG 2.2 level AA. Context (what it is and how it's used): {{context}} Code: {{component_code}} Check at least: semantic structure and headings; accessible names for controls, images and icons (1.1.1, 4.1.2); keyboard operability and no keyboard traps (2.1.1, 2.1.2); visible focus (2.4.7) and focus not obscured (2.4.11); focus order (2.4.3); colour contrast where colours are visible in the code (1.4.3, 1.4.11); information not conveyed by colour alone (1.4.1); form labels, errors and instructions (3.3.1, 3.3.2); target size (2.5.8); status messages announced (4.1.3); motion and reduced-motion preferences. For each issue: the criterion number, the line or element, who is affected, and a code fix. Mark items you cannot judge from code alone (e.g. contrast over images) as "Needs manual check".3Manual pass (15 minutes)
☐ Unplug the mouse: complete the main task with Tab, Shift+Tab, Enter, Space, arrows and Escape. ☐ Zoom to 200% and 400% (reflow at 320px width): no lost content or horizontal scroll for text. ☐ Screen reader: VoiceOver (macOS/iOS) or NVDA (Windows) — are names, roles, states and errors announced sensibly? ☐ Turn on reduced motion and check animations. ☐ Check error states, not just the happy path.
4Fix and record
Fix blockers first (anything that prevents completing the task). Add regression tests where possible, such as an automated axe check and keyboard interaction tests.
Example input
A custom modal built from divs, with an icon-only close button and a form inside.
Example output
4.1.2 Name, Role, Value — line 12: the dialog container is a <div> with no role="dialog", aria-modal or label. Screen-reader users aren't told a dialog opened. Fix: use the native <dialog> element or add role="dialog" aria-modal="true" aria-labelledby="edit-profile-title". 2.1.2 No Keyboard Trap / focus management — focus isn't moved into the dialog on open or returned on close. Fix: focus the first field on open; restore focus to the trigger on close. 1.1.1 / 4.1.2 — line 18: the close button contains only an SVG icon. Fix: aria-label="Close".
Troubleshooting
- Review cites the wrong criterion numbers: verify against the official WCAG 2.2 Quick Reference.
Known limitations
- Neither automated tools nor AI review can confirm conformance; manual testing with assistive technology is required.
- This workflow is not a legal compliance audit.