Accessibility Code Review

The Problem

Accessibility failures lock out 15% of the global population and expose businesses to legal liability. Developers build custom dropdowns that only work with a mouse, use div-soups that screen readers cannot parse, and pick color combinations that disappear for colorblind users. Most of these issues are invisible during development because sighted developers testing with a mouse never encounter them.

The Prompt

Review the following frontend code for accessibility compliance. Act as a WCAG 2.2 AA auditor examining the source code before automated testing.

FRAMEWORK: [e.g., React, Vue, Astro, HTML/CSS]
COMPONENT TYPE: [e.g., navigation menu, form, modal dialog, data table]

CODE:
[paste your component code here]

Audit against these WCAG 2.2 AA criteria:

1. **Semantic Structure**
   - Are correct HTML elements used (button not div[onClick], nav, main, header)?
   - Is heading hierarchy logical (h1 → h2 → h3, no skipped levels)?
   - Are lists marked up as ul/ol, not div sequences?

2. **Keyboard Navigation**
   - Can all interactive elements be reached via Tab?
   - Is focus order logical (follows visual layout)?
   - Can modals/dropdowns be closed with Escape?
   - Is there a visible focus indicator on every interactive element?
   - Are keyboard traps present (focus enters but cannot leave)?

3. **ARIA Usage**
   - Are ARIA roles, states, and properties used correctly (not redundantly)?
   - Do custom widgets follow WAI-ARIA design patterns?
   - Are aria-live regions used for dynamic content updates?
   - Are aria-label/aria-labelledby present on elements without visible text?

4. **Visual Accessibility**
   - Do text colors meet 4.5:1 contrast ratio (3:1 for large text)?
   - Is information conveyed by more than color alone?
   - Can the page be zoomed to 200% without loss of content?
   - Are touch targets at least 44x44px?

5. **Forms**
   - Does every input have a visible, associated label?
   - Are required fields indicated programmatically (aria-required)?
   - Are error messages linked to inputs (aria-describedby)?
   - Is form validation announced to screen readers?

6. **Media and Images**
   - Do images have meaningful alt text (not "image" or filename)?
   - Do decorative images have alt="" or role="presentation"?
   - Are videos captioned? Audio described?

For each issue, provide:
- **WCAG Criterion**: e.g., 2.1.1 Keyboard, 4.1.2 Name Role Value
- **Severity**: critical (blocks access) / serious (major barrier) / moderate / minor
- **Impact**: Which users are affected (screen reader, keyboard, low vision, motor)
- **Fix**: Corrected code

Example Output

## Accessibility Review: 6 issues found

### Critical — WCAG 2.1.1: Keyboard Inaccessible Dropdown
Location: src/components/Dropdown.tsx:8
Issue: Custom dropdown uses div with onClick — unreachable by keyboard.
Impact: All keyboard and screen reader users cannot operate this control.
Fix:
  // Before
  <div onClick={toggle}>Select option</div>
  // After
  <button aria-haspopup="listbox" aria-expanded={isOpen} onClick={toggle}>
    Select option
  </button>
  <ul role="listbox" aria-label="Options">
    {options.map(opt => (
      <li role="option" aria-selected={opt === selected} tabIndex={0}>{opt}</li>
    ))}
  </ul>

### Serious — WCAG 1.3.1: Missing Form Labels
Location: src/components/SearchBar.tsx:5
Issue: Input has placeholder but no <label> element.
Fix: <label htmlFor="search" className="sr-only">Search</label>
     <input id="search" placeholder="Search..." />

When to Use

Run this on every UI component before merge — especially forms, navigation, modals, and interactive widgets. Critical before launching public-facing sites in jurisdictions with accessibility mandates (EU EAA 2025, ADA, AODA). Use it as a shift-left accessibility gate that catches issues before they reach QA.

Pro Tips

• Test one component at a time — accessibility issues compound in page context. Review individual components first, then full page compositions.
• Ask for screen reader narration — follow up with “Walk through this component as a screen reader would announce it, step by step” to hear what blind users experience.
• Combine with automated tools — this review catches what axe/Lighthouse miss: logical focus order, meaningful alt text, and correct ARIA patterns.