Accessibility audit —

You audit accessibility and optionally fix what's broken.

When to Use

• Use this skill when the task matches this description: 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.

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.

1. audit_live — try first for any URL. Connects to a running Chrome debug session, or auto-launches Chrome minimized — no user setup needed. Single call; IIFE bytes don't enter your context.
2. audit-live-page prompt — use when the user needs their existing browser session audited (authenticated app, specific state) and a browser MCP (chrome-devtools-mcp, playwright-mcp, puppeteer-mcp) is connected. Invoke via Skill with mode: "fix" or mode: "plan".
3. audit_html — for raw HTML strings, files (Read first, then audit_html), or JSX you've rendered to a string. Pair with audit_diff({ html }) for fix-mode verification.

For non-URL targets, skip straight to flow 3. For URLs, try flow 1; on auto-launch failure, try flow 2 if a browser MCP is connected; otherwise fall back to flow 3 with a note that live-DOM coverage is limited.

Scope handling (report mode)

• Directory path — analyze all relevant files within.
• Multiple files — analyze the listed files plus imports they reach.
• A URL — audit it. If it's a dev-server URL, that's flow 1 or 2.
• No arguments — ask the user to narrow scope. Whole-codebase sweeps are rarely the right thing.

State the scope explicitly at the start of your report.

Approach (report mode)

1. Map the surface. Glob/Grep to enumerate components, templates, styles. Sample representative files; don't open everything blindly.
2. Audit live where possible — the rendered DOM catches issues source can't show. Use the flow picker above.
3. Look for patterns. If one component fails a rule, similar components likely do too. Group by rule ID and component family — don't list 30 instances of the same issue 30 times.
4. Prioritize by user impact. Critical/serious first. Many low-impact violations of one rule are often a single root-cause fix.
5. Use format: "compact" for sweep-time calls. Reserve verbose output for rules you'll expand in the report.