accessibility-feedback

Accessibility Feedback

Use the connected wcag-accessibility MCP server to turn accessibility from a prompt reminder into a measured correction loop.

Capability boundary

The stable server can render web interfaces, run automated axe rules, calculate contrast, expose affected selectors and DOM, and suggest simple passing colors. It returns a versioned evidence envelope and level-aware profile status, but it cannot prove WCAG conformance or replace keyboard, screen-reader, zoom, reflow, motion, cognitive, and content testing.

All server tools are read-only. Code changes belong to the agent's normal edit workflow and must follow the user's authorization, diff review, and project tests.

Experimental adapters (audit_matrix, compare_audits, inspect_design_snapshot, inspect_screenshot, and browser_diagnostics) are available only when explicitly enabled with A11Y_MCP_ENABLE_EXPERIMENTAL_TOOLS=true. Always verify implementation readiness with the stable rendered DOM tools before relying on design or screenshot evidence.

Audit loop

1. Identify the target, critical user task, relevant routes/states, and supported breakpoints.
2. Start the application if needed.
3. Use audit_url, audit_file, or audit_html for the stable single-viewport audit. If experimental tools are enabled, audit_matrix can compare one wide and one narrow viewport (default 1440×900 and 390×844).
4. For canvas, image-heavy, or generated design work, optionally call inspect_design_snapshot or inspect_screenshot before implementation to find visible-copy, target-size, naming, and contrast risks.
5. Call get_wcag_checklist for the selected conformance profile. Use wcag22aa by default; use wcag22aaa only when the user or product requirement explicitly asks for enhanced coverage.
6. Read the structured results. Preserve rule ID, impact, selector, HTML snippet, computed context, W3C criterion, coverage status, and reference link.
7. Group repeated failures by root cause: token, shared component, content pattern, page template, or one-off instance.
8. Prioritize blockers to the critical task, then critical/serious impact, then high-reach repeated defects. Axe impact is evidence, not the entire product priority.
9. Inspect source before editing. Apply the smallest semantic, component, or token-level fix that addresses the root cause.
10. Rerun the same viewport and state. Run existing project tests.
11. Use compare_audits when a baseline report exists. Report resolved findings, unresolved automated findings, new regressions, all required manual criteria, and named manual tests.