audit-and-fix
You close the accessibility loop. The user points you at something with a11y issues; you find them, fix the source, and verify the fixes resolved without introducing new violations.
You have two flows, and which one you use depends on whether a browser MCP is connected:
- Live DOM (preferred) — fires when a browser MCP (chrome-devtools-mcp, playwright-mcp, puppeteer-mcp) is available. The audit runs against the rendered page, catching SPA content, web-font contrast, and post-mount ARIA state.
- Static fallback — fires when no browser MCP is connected. The audit runs against HTML files or strings only.
Pick by checking which mcp__* tools are available to you in this session. If you see chrome-devtools / playwright / puppeteer tools, use the live flow. If not, use the static fallback. Don't ask the user to install a browser MCP — fall back silently and note in the report that some categories of issue (rendered-only) won't be caught.
When to invoke
The user says any of: "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 you to apply it.
Live-DOM flow
- Invoke the
audit-live-pageprompt from the AccessLint MCP withmode: "fix"and the target URL. The prompt owns: navigate → inject IIFE viaaudit_browser_script→ run via the browser MCP's evaluate → collect viaaudit_browser_collect→ map violations to source components → apply edits. - Before the prompt applies edits, confirm scope with the user (which components are in-bounds, what files are off-limits).
- After the prompt finishes, run
audit_diff(audit_name: <same name>)to re-collect a fresh audit and verify the diff shows fixed violations and zero new ones. Re-inject is unnecessary on the same browser session — passinject: falsetoaudit_browser_scriptfor the verification call.
More from accesslint/claude-marketplace
contrast-checker
Color contrast analyzer for WCAG compliance. Use when analyzing color contrast in code files, when user mentions WCAG compliance, color accessibility, contrast ratios, or when discussing colors in UI components. Calculates contrast ratios, identifies violations, and suggests accessible color alternatives that preserve design themes.
286refactor
Accessibility refactoring specialist. Automatically fixes accessibility issues across multiple files. Performs complex refactoring like extracting accessible components, restructuring markup, and implementing proper ARIA patterns.
257use-of-color
Analyzes code for WCAG 1.4.1 Use of Color compliance. Identifies where color is used as the only means of conveying information and recommends additional visual indicators like text, icons, patterns, or ARIA attributes.
245link-purpose
Analyzes code for WCAG 2.4.4 Link Purpose (In Context) compliance. Identifies generic link text, ambiguous links, and links without sufficient context. Recommends descriptive link text and proper ARIA attributes.
241audit
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.
62