WCAG Accessibility Auditor

Purpose: Audit any UI component, page structure, or HTML snippet against WCAG 2.2 Level AA criteria. Produces a structured checklist with pass/fail status for each applicable criterion, specific code-level fixes for failures, and a prioritized remediation plan. Covers all four WCAG principles: Perceivable, Operable, Understandable, and Robust.

Invocation

/a11y-audit

Provide one of:

• HTML snippet — paste raw HTML/JSX of a component
• Component description — describe what it looks like and how it behaves
• URL — describe the page structure (screenshot descriptions work too)

Criteria Checked (WCAG 2.2 AA)

Perceivable

• 1.1.1 Non-text content has text alternatives (alt text on images)
• 1.3.1 Info and relationships conveyed through structure (semantic HTML, ARIA roles)
• 1.3.2 Meaningful sequence — DOM order matches visual order
• 1.3.3 Instructions don't rely solely on shape/color/size/location
• 1.4.1 Color is not the only means of conveying information
• 1.4.3 Contrast ratio ≥ 4.5:1 for normal text, ≥ 3:1 for large text
• 1.4.4 Text can be resized 200% without loss of content
• 1.4.10 Reflow — content works at 320px width without horizontal scroll
• 1.4.11 Non-text contrast ≥ 3:1 for UI components and focus indicators

Operable

• 2.1.1 All functionality available via keyboard
• 2.1.2 No keyboard traps
• 2.4.1 Skip navigation links present for repeated blocks
• 2.4.2 Pages have descriptive titles
• 2.4.3 Focus order is logical and predictable
• 2.4.4 Link purpose clear from link text (no "click here")
• 2.4.7 Keyboard focus is always visible
• 2.5.3 Label in Name — visible label matches accessible name

Understandable

• 3.1.1 Language of the page is set (lang attribute)
• 3.2.1 No unexpected context changes on focus
• 3.2.2 No unexpected changes on input (unless user is warned)
• 3.3.1 Errors are identified and described in text
• 3.3.2 Labels or instructions provided for user input

Robust

• 4.1.1 Valid HTML — no duplicate IDs, proper nesting
• 4.1.2 Name, Role, Value — all UI components have accessible names, roles, and states
• 4.1.3 Status messages programmatically determinable (ARIA live regions)

Output Format

## Accessibility Audit Report

**Component:** [name]
**Standard:** WCAG 2.2 Level AA
**Date:** [today]

---

### Overall Score: [X/28 criteria] — [PASS / FAIL / NEEDS REVIEW]

---

### Critical Failures (fix before launch)

| Criterion | Issue | Fix |
|-----------|-------|-----|
| 1.4.3 | Contrast ratio 2.8:1 on `#999` text | Change to `#767676` (4.54:1) |
| 2.1.1 | Dropdown not keyboard-accessible | Add `tabindex="0"` and keydown handler |

---

### Warnings (fix this sprint)

| Criterion | Issue | Recommendation |
|-----------|-------|---------------|
| 2.4.4 | "Read more" links lack context | Add `aria-label="Read more about [topic]"` |

---

### Passed Criteria

[List of criteria that pass, for confidence]

---

### Quick Fixes

```html
<!-- Before -->
<img src="logo.png">

<!-- After -->
<img src="logo.png" alt="SkillSlap logo">

Remediation Priority

1. [Most critical fix]
2. [Second fix]

---

## Rules

- Never mark a criterion as "pass" if you cannot confirm it from the provided input — use "cannot verify" instead
- Always provide the **specific CSS/HTML/ARIA fix**, not just a description of the problem
- Contrast ratio failures must include the exact hex values and their actual ratio
- If the component has interactive states (hover, focus, error), audit those states separately
- For JSX/React components, output fixes in JSX syntax, not plain HTML
- Color contrast: use the formula `(L1 + 0.05) / (L2 + 0.05)` where L is relative luminance