scan

Audit live web pages for WCAG accessibility violations via Chrome DevTools Protocol.

Updated Aug 11, 2026
One-click install
npx skills add https://github.com/Debindenny/travelplanner-community- --skill scan-debindenny
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: scan
Source: https://github.com/Debindenny/travelplanner-community-/tree/main/travel-planner/claude-marketplace/plugins/accesslint/skills/scan
Command: npx skills add https://github.com/Debindenny/travelplanner-community- --skill scan-debindenny

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires @accesslint/chrome, @accesslint/cli.

What problem does it solve? Manually checking whether a web page meets accessibility standards is slow and error-prone, and generic audit reports often fail to tell you exactly where each violation lives in your source code. This Skill runs an automated WCAG audit against a live page and grounds every violation to a precise DOM selector and source file:line so fixes can start immediately. ## Core Features & Use Cases - Live-page WCAG auditing: Runs the @accesslint/core engine through a debuggable Chrome instance over CDP, returning violations with impact counts, evidence (contrast ratios, missing attributes), and fix guidance. - Flexible targeting: Accepts a URL, a named target from accesslint.config.json (e.g. dev, storybook), or nothing to use the configured default target. - Source-grounded reporting: Maps each violation to its DOM selector and, when available, the originating file:line and symbol, producing a worklist that drives fixes without editing code itself. - Use Case: After shipping a UI change, run the scan against your dev server to verify the page is accessible, then hand mechanical fixes off and re-run to verify. ## Quick Start Ask the assistant to scan your local dev page for accessibility issues, for example by saying "run an accessibility scan on http://localhost:3000 and list the violations".

Frequently Asked Questions about scan

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I audit a web page for accessibility violations?▼

Pass a URL or a target name from accesslint.config.json to the scan command, which launches a debuggable Chrome via @accesslint/chrome and runs the @accesslint/core engine over CDP. The result is a JSON worklist of WCAG violations with selectors, impact counts, and evidence.

How do I scan a specific page target like a dev server or Storybook?▼

Define named targets such as dev or storybook in accesslint.config.json, then pass the target name to the scan command. Omitting the target audits the config's default target, and an unknown name makes the CLI list the available targets.

Does the accessibility scan fix the violations it finds?▼

No, the scan only locates and reports violations with selectors, source file:line mappings, and suggested fixes. Mechanical fixes are applied separately and verified by re-running the scan, while bulk remediation is handed off to the accesslint:audit workflow.

Why does the accessibility scan fail with exit code 2?▼

Exit code 2 means the URL or target was invalid or the page never loaded, so check that your dev server is running and reachable. Also confirm the target name exists in accesslint.config.json, since unknown names cause the CLI to list valid targets.

Can I filter which accessibility rules or page regions get scanned?▼

Yes, the CLI supports flags like --selector to scope the audit, --wait-for to delay until an element appears, --include-aaa for stricter rules, and --disable to skip specific rules. These options can also be pinned per target in accesslint.config.json.