For QA & CI engineers
Fail the build on accessibility regressions — not after launch.
Accessibility belongs in the same gate as your tests. The @wcag-checkr/ci runner emits SARIF (for GitHub PR annotations) and JUnit (for your test reporter), exits non-zero on the threshold you set, and — crucially — reports delta-only, so a PR fails on the violations it *introduced*, not the 400 you inherited.
Most accessibility tooling floods you with the whole backlog on every run, so teams mute it and it rots. A gate only works if it fires on the new thing — the regression this PR added — and stays quiet about debt you’ve already triaged.
That’s the difference between a check developers respect and one they add to the ignore list.
Start free — wire it into your pipeline
The CI runner and the exports are free, forever.
- CLI runner (@wcag-checkr/ci) with --watch and threshold-based exit codes
- SARIF export — GitHub PR annotations inline on the diff
- JUnit XML — drops into your existing test reporter
- Per-component baselines + delta-only (gate on NEW violations only)
When you scale it across the suite
Unlock inside the app — $99/mo, or Team seats for the org.
- Parallel scan — N hidden tabs run states concurrently for speed
- All-frames audit — every iframe, not just the top document
- Unlimited baselines + cloud-synced, team-shared dismissals
- Auto-export after each scheduled run
Deterministic by design
A gate that flip-flops is worse than no gate. axe-core is pinned at 4.11.4 and the matrix is reproducible, so the same commit produces the same verdict every run — no flaky red builds from sampling variance.
Catch the regression in the PR. Free CLI, SARIF + JUnit, delta-only.
No checkout here — on purpose. Install free, run it on your real site, and unlock the rest inside the app when the evidence is worth it to you.
Not your situation? I got a demand letter · I need defensible evidence · I run audits for clients