Accessibility (WCAG) Auditor
Audits UI against WCAG 2.2 AA — contrast, keyboard, focus, ARIA, alt text, labels — reporting each issue with severity and a fix.
What this skill does
Key features
- Checks against WCAG 2.2 AA success criteria, not vague best practice
- Covers contrast, keyboard operability, focus order, ARIA, alt text, and labels
- Reports each issue with the specific criterion, severity, and a concrete fix
- Verifies contrast ratios and roles rather than guessing
Use cases
- Pre-release accessibility pass on a new component or page
- Finding keyboard traps and missing focus indicators
- Checking form controls have programmatic labels
SKILL.md
The skill definition — its metadata and the exact instructions an agent follows. Copy it into a SKILL.md file in your agent's skills folder.
| name | accessibility-audit |
|---|---|
| description | Audit UI against WCAG 2.2 AA and report issues with criterion, severity, and a concrete fix. |
| allowed-tools | Read, Grep, Bash(npx axe:*) |
| output | WCAG issue report |
| standard | WCAG 2.2 AA |
Musts
- Evaluate against specific WCAG 2.2 AA success criteria and cite the criterion number for every finding.
- Compute and report actual color contrast ratios; do not eyeball or assume them.
- Check keyboard operability: every interactive element reachable and operable by keyboard, visible focus indicator, no keyboard traps, sensible focus order.
- Verify accessible names: form controls have programmatic labels, images have appropriate alt (or empty alt if decorative), buttons and links have discernible text.
- Mark criteria that require human judgement (meaningful alt text, screen-reader flow) as “manual review” rather than passing or failing them automatically.
Guidelines
- Prefer native HTML semantics over ARIA; flag ARIA that duplicates or contradicts native roles.
- Order findings by severity: blockers (unusable by keyboard or AT) first, then serious, then minor.
- Give each fix as a concrete snippet or attribute change, not “add a label somewhere”.
- Note assumptions about dynamic states you could not exercise statically.
Output format
## Accessibility audit (WCAG 2.2 AA)
summary: <n blockers, n serious, n minor, n manual-review>
### [BLOCKER] <short title> — WCAG 2.2 AA <criterion, e.g. 1.4.3 Contrast>
where: <file:line or selector>
problem: <what fails and why>
fix: <concrete snippet or attribute>
### [MANUAL] <short title> — WCAG 2.2 AA <criterion>
where: <selector>
check: <what a human must verify>FAQ
Does it guarantee full WCAG compliance?
No tool or agent can. It reports concrete, checkable failures against WCAG 2.2 AA with fixes. Some criteria need human judgement (e.g. whether alt text is meaningful), and it marks those for manual review rather than passing them silently.
Does it change my markup?
It proposes fixes as diffs or snippets; a human applies them. It reports what it can verify, such as computed contrast ratios and missing labels, and flags what needs manual testing with a screen reader.
Before running any skill, read its instructions and the tools it's allowed to use, and test it on a safe target first. See LLM security best practices.