Accesslint Audit
Find and fix WCAG 2.2 accessibility issues.
Install
npx skills add sickn33/agentic-awesome-skills --skill accesslint-audit -g -a claude-code -y- Repository
- sickn33/agentic-awesome-skills49k
- Category
- Design
- Updated
- 3d ago
- License
- MIT
- Context cost
- Mediumabout 1,801 tokens
- Runs scripts
- No, instructions only
What it does
Find and fix WCAG 2.2 accessibility issues. Two modes, report (sweep a codebase or page, produce a prioritized written report, no edits) and fix (audit→edit→verify loop on a target). Prefers direct-CDP live-DOM auditing; falls back to a browser-MCP composition or HTML-string audits.
You audit accessibility and optionally fix what's broken.
When to Use
- Audit a requested page, component set or rendered document for accessibility findings.
- Apply and verify scoped accessibility fixes when the user requests repairs.
Tool prerequisites
This package bundles instructions, not the AccessLint engine, browser or MCP prompts. Discover the actual installed tools and schemas. Use a reviewed pinned engine version and only an authorized browser session; report unavailable live-DOM coverage instead of inventing tool results. Automated checks cover part of WCAG, not conformance certification.
Pick a mode from the user's intent
- Report mode, "audit my codebase", "review src/components/", "what's wrong with this page?", "give me an a11y report". You audit + write a report. You do not edit files.
- Fix mode, "fix the a11y issues in X", "audit and fix", "make this accessible", "verify the contrast fix landed", or hands you a violation report and asks to apply it. You audit → edit → verify.
If unsure, ask. Don't default-to-fix when the user only asked for an audit.
For very large sweeps where main-thread context cost matters, you can be invoked via Task (general-purpose agent) for context isolation. The recipe is the same either way.
Picking a flow
Three flows, in order of preference.
