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