accessibility-audit
Whole site or product — a full web accessibility (a11y) audit against WCAG 2.2, following the WCAG-EM methodology. Defines scope,…
One page, automated tier — run the web accessibility (a11y) rule engine against a live page and locate every violation it can detect mechanically. Pass a URL, a config target name (e.g. `accesslint:accessibility-scan dev`), or nothing to use the default target from
$ npx -y skills add AccessLint/skills --skill accessibility-scan --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/accessibility-scanContext preview
The summary Claude sees to decide when to auto-load this skill.
One page, automated tier — run the web accessibility (a11y) rule engine against a live page and locate every violation it can detect mechanically. Pass a URL, a config target name (e.g. `accesslint:accessibility-scan dev`), or nothing to use the default target from
name: accessibility-scan description: "One page, automated tier — run the web accessibility (a11y) rule engine against a live page and locate every violation it can detect mechanically. Pass a URL, a config target name (e.g. `accesslint:accessibility-scan dev`), or nothing to use the default target from `accesslint.config.json`. Ensures a debuggable Chrome, runs the @accesslint/core engine over CDP, and returns a worklist of live-DOM WCAG 2.2 violations, each grounded to its DOM selector and source `file:line`. Locates; doesn't edit. Use it for 'is this page accessible', 'check a11y on this URL', 'find contrast and alt-text issues', or to verify a UI change. For hands-on keyboard and screen-reader checks use `accessibility-inspect`; for a whole site or product use `accessibility-audit`; to diff against uncommitted changes or a branch use `accessibility-diff`." argument-hint: "[target|url]" allowed-tools: Bash, Read, Glob, Grep, Skill, Task
Audit a live page and report each violation and where it is. Locate; don't fix.
Shared grounding and honesty conventions: [`../shared/methodology.md`](../shared/methodology.md).
`$ARGUMENTS` is a URL, a config target name (`dev`, `storybook`, …), or empty to audit the default target from `accesslint.config.json`. If it's empty and no config exists, ask for a URL or suggest `npx @accesslint/cli init`.
PORT=$(npx -y @accesslint/chrome@latest ensure | node -e 'process.stdin.on("data",d=>process.stdout.write(""+JSON.parse(d).port))')
npx -y @accesslint/cli@latest scan <target> --port "$PORT" --format json`<target>` is the URL or config target name from `$ARGUMENTS`. Omit it (don't pass `""`) to audit the config's default target. Add flags as needed: `--selector`, `--wait-for "<selector>"`, `--include-aaa`, `--disable <rules>`, or pin them per-target in `accesslint.config.json`.
Counts by impact, then one entry per violation:
Don't edit. For fixes, apply the mechanical ones and re-run to verify; for bulk work hand off to `accesslint:accessibility-fix`.
npx -y @accesslint/chrome@latest stop --all # skip if ensure reported "managed":false
Agent Skills for finding and fixing web accessibility issues, powered by @accesslint/core.
Whole site or product — a full web accessibility (a11y) audit against WCAG 2.2, following the WCAG-EM methodology. Defines scope,…
Regression check — diff a live page's web accessibility (a11y) violations against a baseline. By default it compares your…
Remediation only — repair web accessibility (a11y) violations against WCAG 2.2 with a baseline, edit, and verify loop. Takes a…
One page, hands-on manual tier — drive a live page through the web accessibility (a11y) checks a rule engine can't decide:…