accesslint-scan

1Audit a live page and report what's broken and where. Locate; don't fix. If no URL in `$ARGUMENTS`, ask for one.
2 
3## When to Use
4- A supplied page needs an automated contrast, accessible-name, or semantic-markup audit.
5- You need selector-grounded findings after a UI change, without modifying the application.
6- Manual assistive-technology checks or site-wide conformance assessment are separate work.
7 
8## 1. Audit
9 
10Use an already reviewed, project-pinned installation of `@accesslint/chrome` and
11`@accesslint/cli`; confirm their local binaries and CLI help before execution.
12Do not silently download and execute `@latest`. Confirm the URL and whether
13browser access could expose authenticated or sensitive content.
14 
15For a project whose locked installation exposes these binary names:
16 
17```bash
18session_file="$(mktemp)"
19./node_modules/.bin/accesslint-chrome ensure > "$session_file"
20```
21 
22Read the complete JSON result once, record `port` and `managed`, and substitute
23the returned port in `./node_modules/.bin/accesslint scan "<target>" --port "<returned-port>" --format json`. Never parse arbitrary
24stdout chunks as complete JSON. Confirm the actual binary names from the
25installed packages; they may differ by version. The current upstream command
26shape is `scan <target> --port <port> --format json`.
27 
28 
29Flags as needed: `--selector`, `--wait-for "<selector>"`, `--include-aaa`, `--disable <rules>`.
30 
31## 2. Report
32 
33Counts by impact, then one entry per violation:
34…