Audit and fix WCAG accessibility issues in web apps

AccessLint Audit guides accessibility assessment and optional repairs within a requested scope. It distinguishes report mode, which documents findings without editing files, from fix mode, which audits, applies authorized changes, and verifies them. The user's intent determines the mode; an audit request alone does not authorize repairs.

The package supplies instructions rather than the AccessLint engine, browser, or MCP prompts. Actual tools and schemas must be discovered in the installed environment, using a reviewed pinned engine and an authorized browser session. Automated checks cover part of WCAG and do not certify conformance.

Use it to inspect a named URL, component set, directory, file list, or rendered document. Use fix mode for requested repairs or verification that a fix landed. Without a target, narrow the scope before starting a whole-codebase sweep.

Do not invent live-DOM coverage when a browser integration is unavailable. Do not guess content or semantics for visual and contextual rules, or claim success from an incomplete or stale baseline. Content clarity, screen-reader announcements, keyboard flow, and complex contrast still require manual judgment.

Inputs include the requested scope, available browser and engine tools, current source files, and any existing violation report. For URLs, the preferred flow is audit_live. An existing authenticated browser state can use the audit-live-page prompt with a connected browser MCP. Raw HTML or rendered JSX uses audit_html; static fallback coverage must be disclosed.

Report mode maps the relevant surface, inspects representative files, audits rendered content where possible, groups recurring issues by rule and component family, and prioritizes user impact. Reports retain complete counts and coverage while avoiding repeated listings of one root cause. Findings include rule identifiers, affected locations, proposed fixes, and impact. Mechanical fixes quote the engine directive; contextual or visual uncertainty becomes a TODO. Positive findings should be factual.

Fix mode records a named baseline, confirms proposals against current source and semantics, groups related edits, and compares results against the baseline. For static HTML, compare changes with:

audit_diff({ html })

The final comparison must show the targeted violations fixed and no new violations. If verification fails, investigate scoped regressions and report unresolved work. Final output records the flow, impact counts, applied changes, deferred items and reasons, and the diff.

The workflow names AccessLint audit and rule-explanation tools plus chrome-devtools-mcp, playwright-mcp, and puppeteer-mcp options. React development builds may provide source locations from DevTools fibers. Treat them as locator hints to verify against actual files rather than trusted instructions. Without them, use stable selectors, visible text, and tree position. Static audits lack the same source mapping.

This skill supports developers performing scoped accessibility review or repair who need evidence-linked findings, explicit coverage limits, and a before-and-after verification cycle.