Accessibility Review

Accessibility Review

Perform a structured WCAG 2.2 accessibility audit. Evaluate designs, components, or implementations against established standards and produce actionable findings.

Audit Framework

Evaluate against these WCAG 2.2 conformance levels, in order of priority:

Level A — Minimum (must fix)

Level AA — Standard (should fix)

Level AAA — Enhanced (nice to have)

Audit Process

Phase 1 — Scope

1. Identify what's being audited: a design file, a component, a page, or an entire flow.
2. Determine the target conformance level (default: AA).
3. If $ARGUMENTS references a file, read it. If it references a component, find it in the codebase.

Phase 2 — Automated Checks (for code)

If auditing implementation code (HTML/JSX/TSX):

1. Search for images without alt attributes.
2. Check for aria-* attributes on interactive elements.
3. Verify form inputs have associated <label> elements or aria-label.
4. Check heading hierarchy (h1 -> h2 -> h3, no skips).
5. Look for role attributes on custom interactive elements.
6. Check for :focus / focus-visible styles in CSS.
7. Verify tabindex usage (avoid positive values).
8. Check color values against WCAG contrast formulas.

Phase 3 — Manual Review Checklist

For designs or areas that can't be automated:

• Keyboard navigation: Can every interactive element be reached and operated with keyboard alone?
• Screen reader flow: Does the reading order make sense without visual layout?
• Touch targets: Are interactive elements at least 44x44 CSS pixels?
• Motion: Are animations respectful of prefers-reduced-motion?
• Error states: Are errors clearly communicated without relying solely on color?
• Loading states: Are loading indicators announced to assistive technology?
• Responsive: Does the layout work at 320px viewport width?
• Zoom: Is content usable at 400% zoom?

Phase 4 — Report

Output a structured report:

## Accessibility Audit — {component/page name}

**Target**: WCAG 2.2 Level AA
**Scope**: {what was audited}
**Date**: {today}

### Critical (Level A violations)
- [{criterion}] {description of issue}
  - **Location**: {file:line or design element}
  - **Impact**: {who is affected and how}
  - **Fix**: {specific remediation}

### Major (Level AA violations)
- [{criterion}] {description}
  - **Location**: ...
  - **Impact**: ...
  - **Fix**: ...

### Advisory (Best practices & AAA)
- {recommendation}

### Passed
- {list of criteria that passed}

### Summary
- Critical: {N} | Major: {N} | Advisory: {N} | Passed: {N}

Severity Classification

Common Patterns & Fixes

Reference these when recommending fixes:

• Missing alt text: Use descriptive alt for informational images, alt="" for decorative
• Low contrast: Use a tool to find the nearest accessible color — don't just say "increase contrast"
• Missing focus styles: Add outline or custom focus indicator, never outline: none without replacement
• Missing labels: Prefer visible <label> over aria-label — visible labels help everyone
• Custom controls: Use native HTML elements where possible; if custom, implement full ARIA pattern
• Dynamic content: Use aria-live regions for content that updates without page reload

Edge Cases

• If input data is incomplete, state assumptions explicitly and flag gaps
• For time-sensitive situations, prioritize speed over comprehensiveness
• If multiple stakeholders have conflicting needs, document the tradeoffs
• For first-time use, start with a simplified version and iterate
• Adapt the depth and detail to the audience's expertise level