accessibility-review

# Accessibility Review

## Overview

This skill enables manual accessibility reviews of web content, components, and applications against WCAG 2.1/2.2 Level AA standards. Reviews focus on practical, modern accessibility requirements without being overly pedantic.

## When to Use This Skill

Use this skill when the user asks questions like:
- "Is this accessible?"
- "Can you review the color contrast?"
- "Check this component for accessibility issues"
- "Does this meet accessibility standards?"
- Any request to review, check, or validate accessibility

## Review Process

### 1. Identify the Target

Determine what needs to be reviewed:
- Specific component (button, form, modal, etc.)
- Full page or application
- Code file or set of files
- Design mockup or screenshot

### 2. Conduct Manual Review

Use the WCAG checklist in `references/wcag-checklist.md` to systematically review the target against modern accessibility standards.

Focus on the most common and impactful issues:
- **Perceivable**: Color contrast, text alternatives, semantic structure
- **Operable**: Keyboard navigation, focus management, interactive elements
- **Understandable**: Clear labels, error handling, consistent navigation
- **Robust**: Valid HTML, ARIA usage, compatibility

### 3. Prioritize Findings

Classify each issue as:

**Critical** - Blocks users from accessing core functionality:
- Missing alt text on meaningful images
- Non-keyboard accessible interactive elements
- Insufficient color contrast (below 4.5:1 for normal text, 3:1 for large text)
- Forms without proper labels
- Missing focus indicators
- Inaccessible modal/dialog patterns
- Auto-playing media without controls

**Warning** - Creates friction but doesn't fully block access:
- Suboptimal heading hierarchy (skipped levels)
- Missing ARIA landmarks
- Link text that's unclear out of context
- Redundant or unnecessary ARIA
- Touch targets smaller than 44x44px
- Missing skip links
- Non-descriptive error messages

### 4. Stepped Review (One Issue at a Time)

**IMPORTANT**: Do NOT present all findings at once. Review issues one at a time, waiting for user decision before proceeding.

**4.1 Start with Overview**

Begin by telling the user how many issues were found:

```
Found [X] accessibility issues ([Y] critical, [Z] warnings).

Let's review them one at a time. I'll present each issue with a recommended fix, and you can decide to:
- **Fix** — I'll implement the change
- **Ignore** — Tell me why, and I'll note it

Starting with critical issues first.
```

**4.2 Present Each Issue**

For each issue, present ONE at a time using this format:

```
───────────────────────────────────
Issue [1/X]: [Critical/Warning]
───────────────────────────────────

**Problem**: [Clear description of the issue]

**Location**: `file_path:line_number`
[Show the relevant code snippet]

**Impact**: [How this affects users — be specific about who and how]

**Recommended Fix**:
[Specific code change or approach]

───────────────────────────────────
Fix this issue, or ignore? (If ignoring, please share why)
```

**4.3 Handle User Response**

**If user says "fix":**
1. Implement the fix
2. Confirm: "Fixed. [Brief description of what changed]"
3. Move to next issue

**If user says "ignore" with reason:**
1. Acknowledge: "Noted — ignoring because: [their reason]"
2. Track the decision (see 4.4)
3. Move to next issue

**If user says "ignore" without reason:**
1. Ask: "Got it. Quick note on why? (Helps for future reference)"
2. Accept any response and move on

**4.4 Track Decisions**

Keep a running tally as you go through issues. After all issues are reviewed, present a summary.

### 5. Final Summary

After reviewing all issues, present a summary:

```
## Accessibility Review Complete

**Reviewed**: [X] issues ([Y] critical, [Z] warnings)

### Fixed ([N])
- [Issue description] — `file:line`
- [Issue description] — `file:line`

### Ignored ([N])
- [Issue description] — Reason: [user's reason]
- [Issue description] — Reason: [user's reason]

### Remaining Concerns
[Any patterns noticed, suggestions for future, or issues that were ignored but warrant reconsideration]
```

## Review Guidelines

**Be Practical**: Focus on issues that genuinely impact users. Modern WCAG 2.1/2.2 Level AA is the standard—avoid over-engineering or citing obscure edge cases.

**Be Specific**: Reference actual code locations using `file_path:line_number` format when possible.

**Be Constructive**: Provide actionable fixes, not just problems. Include code examples when helpful.

**Consider Context**: Some patterns may have accessibility trade-offs. Acknowledge these and suggest the most accessible approach for the use case.

## Common Patterns to Check

### Interactive Elements
- All interactive elements must be keyboard accessible (Enter/Space to activate)
- Focus must be visible with clear indicators
- Custom controls need proper ARIA roles and states

### Forms
- All inputs must have associated labels (explicit or aria-label)
- Error messages must be programmatically associated with fields
- Required fields must be indicated clearly

### Color and Contrast
- Text contrast: 4.5:1 minimum for normal text, 3:1 for large text (18pt+ or 14pt+ bold)
- UI components: 3:1 contrast for interactive elements and their states
- Don't rely on color alone to convey information

### Images and Media
- Meaningful images need descriptive alt text
- Decorative images should have empty alt (alt="")
- Videos need captions, audio content needs transcripts

### Structure
- Use semantic HTML (nav, main, article, etc.)
- Heading hierarchy should be logical (h1 → h2 → h3)
- ARIA landmarks help screen reader navigation

## Resources

This skill includes:

### references/wcag-checklist.md
Comprehensive checklist of WCAG 2.1/2.2 Level AA requirements organized by principle (Perceivable, Operable, Understandable, Robust). Reference this during reviews to ensure thorough coverage of accessibility standards.