Accessibility

---
name: accessibility
description: "WCAG 2.2 compliance, ARIA patterns, keyboard navigation, screen reader support, and inclusive design. Use when: reviewing accessibility, adding ARIA attributes, fixing contrast issues, implementing keyboard navigation, creating accessible forms, building accessible components, WCAG audit."
---

# Accessibility

## When to Use

- Reviewing or auditing UI components for accessibility compliance
- Adding ARIA roles, states, and properties
- Fixing color contrast issues
- Implementing keyboard navigation patterns
- Making forms accessible (labels, errors, grouping)
- Building custom interactive components (modals, menus, tabs)
- Responding to accessibility audit findings

## WCAG 2.2 Quick Reference

### Level A (Minimum)

| Criterion | Requirement |
|-----------|-------------|
| 1.1.1 Non-text Content | All images have meaningful `alt` text or are marked decorative |
| 1.3.1 Info and Relationships | Structure conveyed visually is also in markup (headings, lists, tables) |
| 2.1.1 Keyboard | All functionality available via keyboard |
| 2.4.1 Bypass Blocks | Skip navigation link or landmark regions |
| 4.1.2 Name, Role, Value | Custom controls expose name, role, state to assistive tech |

### Level AA (Target)

| Criterion | Requirement |
|-----------|-------------|
| 1.4.3 Contrast (Minimum) | 4.5:1 for normal text, 3:1 for large text |
| 1.4.11 Non-text Contrast | 3:1 for UI components and graphical objects |
| 2.4.7 Focus Visible | Keyboard focus indicator is clearly visible |
| 2.5.8 Target Size (Minimum) | 24x24 CSS pixels minimum for pointer targets |

## ARIA Patterns

### Rules of ARIA

1. **Don't use ARIA if native HTML works** — `<button>` over `<div role="button">`
2. **Don't change native semantics** — don't add `role="heading"` to a `<button>`
3. **All interactive ARIA controls must be keyboard operable**
4. **Don't use `role="presentation"` or `aria-hidden="true"` on focusable elements**
5. **All interactive elements must have an accessible name**

### Common Patterns

| Component | Key ARIA | Keyboard |
|-----------|----------|----------|
| Modal dialog | `role="dialog"`, `aria-modal="true"`, `aria-labelledby` | Trap focus, Escape to close |
| Tab panel | `role="tablist/tab/tabpanel"`, `aria-selected` | Arrow keys between tabs, Tab into panel |
| Menu | `role="menu/menuitem"`, `aria-expanded` | Arrow keys to navigate, Enter to select, Escape to close |
| Accordion | `<button>` with `aria-expanded`, `aria-controls` | Enter/Space to toggle |
| Alert | `role="alert"` or `aria-live="assertive"` | Announced automatically |
| Status | `role="status"` or `aria-live="polite"` | Announced at next opportunity |

## Keyboard Navigation

- **Tab**: Move between interactive elements
- **Shift+Tab**: Move backward
- **Enter/Space**: Activate buttons and links
- **Arrow keys**: Navigate within composite widgets (tabs, menus, trees)
- **Escape**: Close modals, menus, popups
- **Home/End**: Jump to first/last item in a list

### Focus Management

- Never remove the default focus outline without providing a visible alternative
- Use `tabindex="0"` to make non-interactive elements focusable when needed
- Use `tabindex="-1"` for programmatic focus (e.g., error summary, modal container)
- Never use `tabindex` greater than 0

## Forms

- Every input must have a visible `<label>` with matching `for`/`id`
- Group related fields with `<fieldset>` and `<legend>`
- Mark required fields with `aria-required="true"` and visible indicator
- Associate error messages with `aria-describedby`
- Use `aria-invalid="true"` on fields with validation errors
- Provide error summary at the top of the form on submission failure

## Color and Contrast

- **Text contrast**: 4.5:1 minimum (3:1 for large text — 18pt or 14pt bold)
- **UI component contrast**: 3:1 for borders, icons, and interactive states
- **Don't rely on color alone** to convey information — add icons, text, or patterns
- Test with simulated color blindness (protanopia, deuteranopia, tritanopia)

## Testing Checklist

1. Tab through the entire page — can you reach and operate everything?
2. Use a screen reader (NVDA, VoiceOver, Narrator) to verify announced content
3. Check color contrast with a tool (axe, Lighthouse, Colour Contrast Analyser)
4. Zoom to 200% — does layout remain usable?
5. Test with high contrast mode enabled
6. Verify focus indicators are visible on every interactive element

## Procedure

1. Review the component's semantic HTML structure
2. Verify all interactive elements are keyboard accessible
3. Check ARIA roles, states, and properties against the pattern library
4. Test color contrast for text and UI components
5. Verify focus management (order, visibility, trapping where needed)
6. Test with a screen reader to confirm announced content matches visual content