Uses Chrome DevTools MCP for accessibility (a11y) debugging and auditing based on web.dev guidelines. Use when testing semantic HTML, ARIA labels, focus states, keyboard navigation, tap targets, and color contrast.
Accessibility Tree vs DOM: Visually hiding an element (e.g., CSS opacity: 0) behaves differently for screen readers than display: none or aria-hidden="true". The take_snapshot tool returns the accessibility tree of the page, which represents what assistive technologies "see", making it the most reliable source of truth for semantic structure.
Reading web.dev documentation: If you need to research specific accessibility guidelines (like https://web.dev/articles/accessible-tap-targets), you can append .md.txt to the URL (e.g., https://web.dev/articles/accessible-tap-targets.md.txt) to fetch the clean, raw markdown version. This is much easier to read!
Start by running a Lighthouse accessibility audit to get a comprehensive baseline. This tool provides a high-level score and lists specific failing elements with remediation advice.
mode to "navigation" to refresh the page and capture load issues.outputDirPath (e.g., /tmp/lh-report) to save the full JSON report.scores (0-1 scale). A score < 1 indicates violations.audits.failed count.jq or a Node.js one-liner to filter for failures:
# Extract failing audits with their details
node -e "const r=require('./report.json'); Object.values(r.audits).filter(a=>a.score!==null && a.score<1).forEach(a=>console.log(JSON.stringify({id:a.id, title:a.title, items:a.details?.items})))"
selector and snippet of failing elements without loading the full report into context.Chrome automatically checks for common accessibility problems. Use list_console_messages to check for these native audits:
types: ["issue"]includePreservedMessages: true (to catch issues that occurred during page load)This often reveals missing labels, invalid ARIA attributes, and other critical errors without manual investigation.
The accessibility tree exposes the heading hierarchy and semantic landmarks.
take_snapshot to capture the accessibility tree.h1, h2, h3, etc.) are logical and do not skip levels. The snapshot will include heading roles.take_screenshot to inspect the visual layout and compare it against the snapshot structure to catch CSS floats or absolute positioning that jumbles the logical flow.take_snapshot output."" if it only contains an icon).evaluate_script with the "Find Orphaned Form Inputs" snippet found in references/a11y-snippets.md.alt text.Testing "keyboard traps" and proper focus management without visual feedback relies on tracking the focused element.
press_key tool with "Tab" or "Shift+Tab" to move focus.take_snapshot to capture the updated accessibility tree.According to web.dev, tap targets should be at least 48x48 pixels with sufficient spacing. Since the accessibility tree doesn't show sizes, use evaluate_script with the "Measure Tap Target Size" snippet found in references/a11y-snippets.md.
Pass the element's uid from the snapshot as an argument to evaluate_script.
To verify color contrast ratios, start by checking for native accessibility issues:
list_console_messages with types: ["issue"].If native audits do not report issues (which may happen in some headless environments) or if you need to check a specific element manually, use evaluate_script with the "Check Color Contrast" snippet found in references/a11y-snippets.md.
Verify document-level accessibility settings often missed in component testing using the "Global Page Checks" snippet found in references/a11y-snippets.md.
If standard a11y queries fail or the evaluate_script snippets return unexpected results:
take_screenshot to capture the element. While models cannot measure exact contrast ratios from images, they can visually assess legibility and identify obvious issues.