Use accessibility-audit

Adversarially audit a UI (component code, page markup, screenshot, or flow) against WCAG 2.2 AA

Adversarially audit a UI (component code, page markup, screenshot, or flow) against WCAG 2.2 AA — findings cited to specific success criteria, centered on the user and assistive tech each one blocks, severity-tagged, with a concrete fix and what a scanner would miss.

Reach for it when the user wants an accessibility review, a11y audit, WCAG check, or to find what blocks screen-reader / keyboard / low-vision users before shipping.

Install it

npx skilldrop-cli install accessibility-audit                 # Claude Code, your user folder
npx skilldrop-cli install accessibility-audit --project       # Claude Code, this repo
npx skilldrop-cli install accessibility-audit --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Dev team pack: --pack dev-team installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "Run an a11y audit on this signup page markup"
• "Is this component WCAG 2.2 AA compliant? Find what blocks screen-reader users"
• "Here's a screenshot of our dashboard — what accessibility issues can you spot before we build it?"
• "We failed an accessibility review; check this modal for keyboard traps and focus problems"

Requests like these belong to a different skill, so it shouldn't answer them:

• "What WCAG level should our new product commit to, and on which scope?"
• "Review this PR for correctness bugs and edge cases"
• "Implement this date-picker story with tests until the acceptance criteria pass"

If another skill answers instead, ask for this one by name: "use accessibility-audit".

Check what you get

A good result:

• Every finding cites a specific success criterion (number + name + level). Uncited "issues" are opinions.
• Every finding names the user group and assistive tech it blocks. No victim, no finding.
• Severity reflects task-completion impact, calibrated — not everything is a blocker, and a real keyboard trap is never a minor.
• Contrast and target-size claims are computed numbers against the threshold, not visual guesses.
• Coverage limits are stated and unverifiable checks are listed as must-test-with-AT, never silently passed. A screenshot audit never claims keyboard operability is fine.
• [auto] vs [manual] is tagged, so CI-gateable findings are separated from the human-only ones.
• "What's solid" is present, so good semantics survive the next refactor.

See a worked example

• login form

Use something else when

• Setting the accessibility target (which WCAG level, on which scope) — that's nfr-spec
• General code correctness/security review — that's devils-advocate
• Writing the component — fix findings in your normal build loop, or hand to feature-implement-loop
• A full certified VPAT/conformance attestation — this audit feeds one, but legal sign-off is a formal process beyond a review

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: devils-advocate, doc-critique, feature-implement-loop, nfr-spec, threat-model

Edit this page on GitHub · View source