| name | accessibility |
| description | Apply WCAG 2.2 AA accessibility standards when building or reviewing web UI code. Use this skill whenever the user asks to build, modify, or review any HTML, CSS, or frontend component โ even if they don't explicitly mention accessibility. Also use it when the user asks to "make something accessible", "check for a11y issues", "add ARIA", fix keyboard navigation, or improve screen reader support.
|
Accessibility (WCAG 2.2 AA)
Apply accessibility standards to all web UI work. Read references/guidelines.md for the
full reference โ it covers semantic HTML, keyboard navigation, focus management, ARIA,
images/media, colour contrast, forms, motion, zoom, and a testing checklist.
Workflow
When building new UI:
- Use semantic HTML first โ reach for ARIA only when native elements are insufficient.
- After implementation, run through the Testing Checklist in
references/guidelines.md.
- Flag any items you cannot verify programmatically (screen reader behaviour, contrast on
custom colours) so the user can check them manually.
When reviewing existing UI:
- Scan for the Common Mistakes table in
references/guidelines.md โ these are the
most frequent violations and the quickest wins.
- Report findings grouped by severity: critical (blocks keyboard/screen reader users) โ
serious (WCAG failure) โ moderate (best-practice gap).
- Provide a concrete fix for each finding, not just a description of the problem.
Non-negotiables
These four always apply, regardless of scope:
- Every
<img> has a meaningful or empty alt.
- Every interactive element is reachable and operable by keyboard alone.
- Text contrast meets 4.5:1 (normal) / 3:1 (large / UI components).
- Every form input has a persistent, programmatically associated label.
Quick reference
See references/guidelines.md for detailed rules on all 12 topic areas and the full
testing checklist to run before marking any feature complete.
