Accessibility Implementation
Technical implementation of WCAG guidelines, ARIA patterns, and assistive technology support.
When to Use This Skill
| Use this skill when... |
Use design-tokens instead when... |
| Implementing WCAG 2.1/2.2 success criteria in code |
Setting up CSS custom properties or theme systems |
| Adding ARIA roles, states, or live regions |
Defining semantic colour tokens used by themes |
| Wiring keyboard navigation, focus traps, or skip links |
Organizing primitive/semantic/component token tiers |
| Auditing components with axe-core, jest-axe, or Playwright |
Implementing light/dark mode token overrides |
Core Expertise
- WCAG Compliance: Implementing WCAG 2.1/2.2 success criteria in code
- ARIA Patterns: Correct usage of roles, states, and properties
- Keyboard Navigation: Focus management, key handlers, logical tab order
- Screen Readers: Content structure, announcements, live regions
- Testing: Automated and manual accessibility testing
WCAG Quick Reference
Level A (Must Have)
| Criterion |
Implementation |
| 1.1.1 Non-text Content |
alt for images, labels for inputs |
| 1.3.1 Info and Relationships |
Semantic HTML, ARIA relationships |
| 2.1.1 Keyboard |
All interactive elements keyboard accessible |
| 2.4.1 Bypass Blocks |
Skip links, landmarks |
| 4.1.2 Name, Role, Value |
ARIA labels, roles for custom widgets |
Level AA (Should Have)
| Criterion |
Implementation |
| 1.4.3 Contrast (Minimum) |
4.5:1 text, 3:1 large text |
| 1.4.11 Non-text Contrast |
3:1 for UI components |
| 2.4.6 Headings and Labels |
Descriptive, hierarchical headings |
| 2.4.7 Focus Visible |
Visible focus indicator (2px+ outline) |
Best Practices
Semantic HTML First
Use native HTML elements before ARIA. A <button> is better than <div role="button">.
Don't Override Default Behavior
Native elements have built-in accessibility. Don't break it with JavaScript.
Test with Real Users
Automated tools catch ~30% of issues. Manual testing with assistive technology is essential.
Provide Multiple Ways
Offer keyboard, mouse, and touch alternatives for all interactions.
References
For full ARIA widget patterns, keyboard navigation implementations, testing recipes, common fixes, and CSS utilities, see REFERENCE.md.
1---
2created: 2025-12-16
3modified: 2026-05-09
4reviewed: 2026-04-25
5name: accessibility-implementation
6description: "WCAG 2.1/2.2 compliance, ARIA patterns, keyboard nav, focus management, a11y testing. Use when implementing accessible components or user mentions WCAG/ARIA/screen readers."
7user-invocable: false
8allowed-tools: Glob, Grep, Read, Edit, Write, Bash(npm *), Bash(npx *), Bash(axe *), TodoWrite, WebSearch, WebFetch
9---
10
11# Accessibility Implementation
12
13Technical implementation of WCAG guidelines, ARIA patterns, and assistive technology support.
14
15## When to Use This Skill
16
17| Use this skill when... | Use design-tokens instead when... |
18|---|---|
19| Implementing WCAG 2.1/2.2 success criteria in code | Setting up CSS custom properties or theme systems |
20| Adding ARIA roles, states, or live regions | Defining semantic colour tokens used by themes |
21| Wiring keyboard navigation, focus traps, or skip links | Organizing primitive/semantic/component token tiers |
22| Auditing components with axe-core, jest-axe, or Playwright | Implementing light/dark mode token overrides |
23
24## Core Expertise
25
26- **WCAG Compliance**: Implementing WCAG 2.1/2.2 success criteria in code
27- **ARIA Patterns**: Correct usage of roles, states, and properties
28- **Keyboard Navigation**: Focus management, key handlers, logical tab order
29- **Screen Readers**: Content structure, announcements, live regions
30- **Testing**: Automated and manual accessibility testing
31
32## WCAG Quick Reference
33
34### Level A (Must Have)
35
36| Criterion | Implementation |
37|-----------|----------------|
38| 1.1.1 Non-text Content | `alt` for images, labels for inputs |
39| 1.3.1 Info and Relationships | Semantic HTML, ARIA relationships |
40| 2.1.1 Keyboard | All interactive elements keyboard accessible |
41| 2.4.1 Bypass Blocks | Skip links, landmarks |
42| 4.1.2 Name, Role, Value | ARIA labels, roles for custom widgets |
43
44### Level AA (Should Have)
45
46| Criterion | Implementation |
47|-----------|----------------|
48| 1.4.3 Contrast (Minimum) | 4.5:1 text, 3:1 large text |
49| 1.4.11 Non-text Contrast | 3:1 for UI components |
50| 2.4.6 Headings and Labels | Descriptive, hierarchical headings |
51| 2.4.7 Focus Visible | Visible focus indicator (2px+ outline) |
52
53## Best Practices
54
55### Semantic HTML First
56Use native HTML elements before ARIA. A `<button>` is better than `<div role="button">`.
57
58### Don't Override Default Behavior
59Native elements have built-in accessibility. Don't break it with JavaScript.
60
61### Test with Real Users
62Automated tools catch ~30% of issues. Manual testing with assistive technology is essential.
63
64### Provide Multiple Ways
65Offer keyboard, mouse, and touch alternatives for all interactions.
66
67## References
68
69- WCAG 2.1 Guidelines: https://www.w3.org/WAI/WCAG21/quickref/
70- ARIA Authoring Practices: https://www.w3.org/WAI/ARIA/apg/
71- axe-core Rules: https://dequeuniversity.com/rules/axe/
72- A11y Project Checklist: https://www.a11yproject.com/checklist/
73
74For full ARIA widget patterns, keyboard navigation implementations, testing recipes, common fixes, and CSS utilities, see [REFERENCE.md](REFERENCE.md).
laurigates