Accessibility with AI
AI can audit HTML for WCAG 2.1 and 2.2 violations, generate ARIA attributes, and explain why a pattern is inaccessible and how to fix it. The hard limit is that AI cannot use a screen reader, navigate your UI with a keyboard, or verify that visual colour contrast is actually correct — those require you to test directly. Use AI for code audit and fix generation; use real assistive technology for validation.
Accessibility Code Audit
Paste your component HTML or JSX. Specify which WCAG level you are targeting and any specific assistive technology context.
Audit the following HTML/JSX for accessibility issues. Target: WCAG 2.1 Level AA.
[PASTE YOUR COMPONENT CODE]
For each issue found:
1. WCAG criterion violated (criterion number and name)
2. What the problem is in plain language
3. Who it affects and how (e.g., screen reader users cannot determine the button purpose)
4. The corrected code snippet
After the issues list, add:
- What tests I should run manually that code review cannot verify
- Which issues are P1 (blocks access) vs P2 (degrades experience)
The P1/P2 prioritisation is important — not all WCAG failures equally block usage. AI will catch the obvious ones; the manual test list is where the hard ones surface.
Generating ARIA Labels and Attributes
ARIA attributes require context about the element's role in the UI and how its state changes. Always describe the dynamic behaviour, not just the static markup.
Add appropriate ARIA attributes to the following [COMPONENT TYPE — e.g., "modal dialog with a form inside"].
Current code:
[PASTE COMPONENT CODE]
Behaviour to model:
- [DESCRIBE OPEN/CLOSE BEHAVIOUR — e.g., "opens when user clicks a trigger button; closes on Escape or clicking outside"]
- [DESCRIBE STATE CHANGES — e.g., "submit button is disabled while form is submitting"]
- [DESCRIBE FOCUS BEHAVIOUR — e.g., "focus should move to first form field when modal opens; return to trigger when closed"]
For each ARIA attribute you add, explain why it is needed and what it tells the screen reader.
The explanation-per-attribute request is important — incorrect ARIA is worse than no ARIA. Understanding why each attribute is there lets you catch mistakes before committing.
Keyboard Navigation
Review the following component for keyboard navigation issues. The component is a [DESCRIBE — e.g., "dropdown menu that opens on button click"].
[PASTE COMPONENT CODE]
Check for:
1. Focus trap: when the component is open, can keyboard focus escape to behind it?
2. Expected keyboard pattern: what keys should work (Enter/Space to activate, Escape to close, Arrow keys for navigation)?
3. Focus visibility: is focus indicator visible on all interactive elements?
4. Tab order: does the DOM order match the visual reading order?
5. Missing keyboard handlers: interactive elements that only respond to mouse events
For each issue, provide the corrected event handler code.
The WAI-ARIA Authoring Practices Guide defines the expected keyboard patterns for every common widget (menus, dialogs, tabs, carousels). Link AI to specific pattern if the widget is non-standard.
Common Issues AI Finds Reliably
| Issue | WCAG criterion | AI fix reliability |
|---|---|---|
| Missing alt text on images | 1.1.1 Non-text Content | High — code review is sufficient |
| Buttons without accessible names | 4.1.2 Name, Role, Value | High — detects icon-only buttons missing aria-label |
| Form inputs without labels | 1.3.1 Info and Relationships | High — reliably catches missing label/htmlFor association |
| Missing focus management in modals | 2.4.3 Focus Order | Medium — can suggest code; must test manually |
| Colour contrast | 1.4.3 Contrast (Minimum) | Low — use a dedicated contrast checker; AI estimates only |
| Touch target size | 2.5.8 Target Size (WCAG 2.2) | Low — requires visual layout inspection |
What Requires Manual Testing
AI cannot verify these — test manually
- Screen reader flow: use NVDA+Firefox or VoiceOver+Safari to navigate your page end-to-end
- Colour contrast in context: use Colour Contrast Analyser or browser DevTools; AI guesses from hex values
- Focus trap validation: open a modal and press Tab until you escape (or cannot) — code review misses timing issues
- Touch target size on real devices: 24px minimum in WCAG 2.2 is about physical space, not pixels
- Cognitive load: whether error messages or instructions are understandable to your actual users
- Zoom to 400%: WCAG 1.4.10 Reflow — layout must not require horizontal scrolling at 400% zoom
Checklist: Do You Understand This?
- What does WCAG 2.1 Level AA mean, and why do most organisations target this level?
- Why does AI need to know about state changes and dynamic behaviour when generating ARIA attributes?
- What is the danger of applying incorrect ARIA versus no ARIA?
- Which accessibility issue type can AI check reliably in code, and which requires manual validation?
- Write a keyboard navigation review prompt for a multi-step accordion component.
- Name three WCAG issues that require a human with assistive technology to test — and explain why code review is insufficient for each.