Run a scan on your machine

If you want to check a project for accessibility findings before you push, scan it locally.

b8e scan needs a session. Run b8e auth login once; the scan itself still runs entirely on your machine. BINCLUSIVE_API_KEY does not authenticate it — that variable belongs to b8e ci, which is the command a pipeline runs.

From the project root:

b8e scan .

b8e walks the source and prints a report grouped by file. Each entry names the rule that fired and the WCAG success criterion it maps to.

To scan a subdirectory instead of the whole project, pass its path:

b8e scan ./src/components

If you want machine-readable output — to pipe into another tool, or to read a finding’s exact selector and criterion — ask for JSON:

b8e scan . --format json

To write that output to a file instead of stdout, add --output:

b8e scan . --format json --output findings.json

If you want to scan a live page rather than source, pass --url. Repeat or comma-separate it to aggregate several pages into one report:

b8e scan --url https://example.com/ --url https://example.com/pricing

Where the findings go

Whether a scan sends anything is decided by one thing: the project your session names.

• No project selected — the findings stay on your machine. Nothing is uploaded, and the scan exits 0 whether or not it found anything.
• A project selected (b8e project) — the findings are also filed to that project’s queue on the dashboard, and the run prints where they went. They arrive under the unknown environment, because a scan on your laptop is not production, staging, or a pull request. They are listed in the dashboard’s default all-locations view, but drop out the moment the location filter narrows to a real deployment — pick Undeclared to see them on their own.

Either way b8e scan never gates your build. To fail a build on findings, use b8e ci instead.

For every flag b8e scan accepts, see the scan reference. For what the scanner checks, see the rules catalog.