Accessibility Audit · eblouin-development
Run a thorough, whole-project WCAG 2.2 AA accessibility audit — fingerprint the UI surfaces, map semantics/landmarks, keyboard paths, focus management, contrast (against the design-system tokens), forms/errors, and media alternatives, credit what's already handled with evidence, run automated checks (axe) plus the manual checks automation can't do, deliver an inline audit report, and (after one confirmation) file each finding as a scoped, pipeline-ready GitHub issue. Use this skill WHENEVER the user asks for an accessibility assessment of a project as a whole: \"accessibility audit\", \"a11y audit\", \"is this WCAG compliant\", \"can screen reader users use this\", \"check our contrast/keyboard support\", \"are we ADA compliant\", \"audit this for accessibility\". This is the whole-codebase, point-in-time audit — distinct from frontend/mobile/design-system (which build accessibility in as they ship) and code-review (which checks one diff as it ships). Strictly read-only: it never fixes markup or styles and never runs exploits — remediation flows through the filed issues into the normal plan → PR → review pipeline.
Works with: Claude Code (native) · Cursor, Codex CLI (manual)
native: this artifact type is that client's own format
Category: Design — see all ranked ›
Install (Claude Code):
cp -r accessibility-audit ~/.claude/skills/- Adoption: 1 repos
Security audit
Not scanned yet. We audit npm-published capabilities for known advisories, install-time scripts and permission surface; this one has no npm package we can resolve, or has not reached the queue.
source ↗ · skill:eblouin-development/accessibility-audit
Already running this? npx tashan-cli doctor checks your whole config against the Index — how it works ›
Measured 2026-08-09 · scorer s5 · how · something wrong here?