Accesslint Scan

Audit a live page and report what's broken and where. Locate; don't fix. If no URL in $ARGUMENTS, ask for one.

When to Use

• A supplied page needs an automated contrast, accessible-name, or semantic-markup audit.
• You need selector-grounded findings after a UI change, without modifying the application.
• Manual assistive-technology checks or site-wide conformance assessment are separate work.

1. Audit

Use an already reviewed, project-pinned installation of @accesslint/chrome and @accesslint/cli; confirm their local binaries and CLI help before execution. Do not silently download and execute @latest. Confirm the URL and whether browser access could expose authenticated or sensitive content.

For a project whose locked installation exposes these binary names:

session_file="$(mktemp)"
./node_modules/.bin/accesslint-chrome ensure > "$session_file"

Read the complete JSON result once, record port and managed, and substitute the returned port in ./node_modules/.bin/accesslint scan "<target>" --port "<returned-port>" --format json. Never parse arbitrary stdout chunks as complete JSON. Confirm the actual binary names from the installed packages; they may differ by version. The current upstream command shape is scan <target> --port <port> --format json.

Flags as needed: --selector, --wait-for "<selector>", --include-aaa, --disable <rules>.

2. Report

Counts by impact, then one entry per violation:

• where, selector verbatim + file:line (symbol) if source is present, never fabricate. If no violation has source, note "source mapping unavailable, located by selector only".
• evidence, contrast ratio, missing attribute, empty name
• fix, mechanical change or NEEDS HUMAN

Return the worklist without editing. Remediation requires a separate authorized task; current upstream names it accesslint:accessibility-fix, which may not be installed in this host.

3. Tear down