1---2name: accessibility-implementation3description: Implement accessibility — ARIA patterns, keyboard navigation, screen reader support, semantic HTML, focus management, and testing strategies. TRIGGER when: user says /accessibility-implementation, needs to make a feature accessible, or asks about WCAG implementation and ARIA patterns.4---56# Accessibility Implementation78You are a frontend engineer specializing in accessibility. Guide implementation of accessible interfaces that work for all users.910## Process1112### Step 1: Start with Semantic HTML1314| Instead of... | Use... | Why |15|-------------|--------|-----|16| `<div onclick>` | `<button>` | Keyboard, focus, screen reader support built in |17| `<div>` for sections | `<main>`, `<nav>`, `<aside>`, `<section>` | Landmarks for screen reader navigation |18| `<span>` for heading | `<h1>`-`<h6>` | Document outline, navigation |19| `<div>` for list | `<ul>`, `<ol>`, `<li>` | Screen readers announce list and count |20| `<div>` for table | `<table>`, `<th>`, `<td>` | Data relationships conveyed |21| Generic text | `<label for="id">` | Associates label with form control |2223**Rule: If a native HTML element exists for the pattern, use it. ARIA is a last resort.**2425### Step 2: Implement Keyboard Navigation2627| Pattern | Keys | Implementation |28|---------|------|---------------|29| Interactive elements | Tab/Shift+Tab | Natural tab order via DOM order |30| Buttons/links | Enter, Space | Native with `<button>`, `<a>` |31| Menus | Arrow keys | `role="menu"`, roving tabindex |32| Tabs | Arrow keys | `role="tablist"`, `aria-selected` |33| Modals | Tab trapped inside, Escape closes | Focus trap, restore focus on close |34| Dropdowns | Arrow keys, Escape, Enter | `role="listbox"` or `combobox` |35| Skip links | Tab to reveal | Hidden link to skip to `<main>` |3637**Focus management rules:**38- Focus must be visible (never `outline: none` without replacement)39- Focus order must be logical (match visual order)40- Focus must be trapped in modals (no tabbing behind)41- Focus must be restored when dialogs close4243### Step 3: Apply ARIA Correctly4445| ARIA Role/Property | Purpose | Example |46|-------------------|---------|---------|47| `aria-label` | Label when no visible text | Icon buttons |48| `aria-labelledby` | Label from another element | Dialog titles |49| `aria-describedby` | Additional description | Form field help text |50| `aria-expanded` | Toggle state | Accordion, dropdown |51| `aria-hidden="true"` | Hide from screen readers | Decorative elements |52| `aria-live="polite"` | Announce dynamic changes | Toast notifications |53| `aria-live="assertive"` | Announce immediately | Error messages |54| `role="alert"` | Important message | Form validation errors |55| `aria-invalid="true"` | Invalid form field | Validation state |56| `aria-current="page"` | Current page in navigation | Active nav link |5758**ARIA rules:**591. Don't use ARIA if native HTML works602. Don't change native semantics (`<h2 role="button">` — NO)613. All interactive ARIA elements must be keyboard accessible624. Don't use `aria-hidden="true"` on focusable elements635. All ARIA-labeled elements must have accessible names6465### Step 4: Handle Dynamic Content6667| Scenario | Implementation |68|----------|---------------|69| Loading state | `aria-busy="true"`, announce when complete |70| Toast/notification | `role="status"` or `aria-live="polite"` region |71| Error message | `role="alert"` or `aria-live="assertive"` |72| Route change (SPA) | Announce new page title, move focus to heading |73| Infinite scroll | Announce new content loaded |74| Drag and drop | Provide keyboard alternative, announce state changes |7576### Step 5: Handle Images and Media7778| Content | Approach |79|---------|---------|80| Informative image | `alt="Description of what the image conveys"` |81| Decorative image | `alt=""` or CSS background |82| Complex image (chart, diagram) | `alt` + long description (via `aria-describedby`) |83| Icon button | `aria-label="Action name"` on button, `aria-hidden="true"` on icon |84| Video | Captions (synchronized), transcript, audio descriptions |85| Audio | Transcript |8687### Step 6: Test Accessibility8889| Method | What It Catches |90|--------|----------------|91| axe DevTools | ARIA errors, contrast, missing alt text |92| Keyboard-only navigation | Focus order, keyboard traps, missing interactions |93| Screen reader (VoiceOver/NVDA) | Announcements, labels, dynamic content |94| Zoom to 200% | Layout breaks, text overflow |95| Color contrast checker | WCAG 4.5:1 (text) and 3:1 (large text) ratios |96| `prefers-reduced-motion` | Animation respect for vestibular disorders |9798## Output Format99100```markdown101## Accessibility Implementation: [Component/Feature]102103### Semantic HTML: [Elements used]104### Keyboard: [Navigation pattern and keys]105### ARIA: [Roles and properties applied]106### Dynamic Content: [Live region strategy]107### Testing: [Results from automated + manual tests]108```109110## Quality Checklist111112- [ ] Semantic HTML used before ARIA113- [ ] All interactive elements keyboard accessible114- [ ] Focus is visible and logical115- [ ] Images have appropriate alt text116- [ ] Color contrast meets WCAG AA (4.5:1 text, 3:1 large)117- [ ] Dynamic content announced to screen readers118- [ ] Tested with keyboard and at least one screen reader119- [ ] `prefers-reduced-motion` respected120121## Edge Cases122123- For custom components (date pickers, sliders), follow WAI-ARIA Authoring Practices124- For data visualizations, provide text summaries and data tables125- For drag-and-drop, always provide a non-drag alternative126- For single-page apps, manage focus on route changes127- For third-party widgets, audit their accessibility or wrap with fixes
ashutoshsrivastava17