Playwright Accessibility Audit

Two layers, run together: an automated axe-core scan (fast, reliable, covers the WCAG criteria that are actually mechanically checkable) plus a short manual-check pass for the things automated tools structurally can't judge — keyboard operability, focus order, whether alt text is actually meaningful rather than merely present. Roughly 30% of WCAG success criteria are testable by software; the other 70% is why the manual layer exists, not an afterthought bolted onto axe's output.

Relationship to the other skills

scenario-mapper and flow-runner both read the accessibility tree as part of normal operation and may note something obviously wrong in passing — that's a side effect, not an audit. If the user has already run the mapper, its CSV's area column is a good source of pages/flows to audit here rather than rediscovering the site's structure from scratch. If a flow-runner scenario passes through a modal, dropdown, or validation-error state, those are exactly the states worth auditing here too — dynamic states are where automated single-page-load scans miss the most.

Before you start

Same tool check as the rest of the toolkit (@playwright/cli vs MCP browser_* tools) — but this skill specifically needs whichever one lets you evaluate/execute JavaScript in the page context, since that's how axe-core gets run.

Get axe-core's source before you touch the browser:

1. Check for a local install first: node_modules/axe-core/axe.min.js in the current project.
2. If it's not there, install it: npm install axe-core --no-save (throwaway, doesn't need to touch the project's real dependencies).
3. Read the file's contents into a string — don't reference it by URL.

Injecting the source as a string through your evaluate tool, rather than pointing the browser at a CDN URL via a script tag, matters for a reason beyond convenience: a site with a strict Content-Security-Policy can block a <script src="..."> from loading, but code your automation tool injects directly into the page context isn't a resource the page fetched, so CSP's script-src restrictions don't apply to it. This works regardless of how locked-down the target site is.