You may not need this
Three good tools do most of what we do, for nothing, on your own machines. If one of them fits, use it — a page that pretended otherwise would be arguing against the same thing this product argues against everywhere else.
| Tool | Engine | What it fails on | Runs |
|---|---|---|---|
| Pa11y CI | HTML_CodeSniffer by default; axe-core with --runner axe |
A count. --threshold permits N errors, warnings or notices; ignore silences issue codes |
Yours. LGPL-3.0-only |
| Lighthouse CI | Lighthouse's accessibility category, weighted by axe user-impact assessments | Assertions on the category score or on individual audits | Yours. Optional server keeps history |
| @axe-core/cli | axe-core, from the people who write it | Any violation, with --exit. --rules, --tags and --disable narrow the run |
Yours, driving a real browser |
| Skiplink | axe-core, pinned and reported with every result | Violations that are not in a committed baseline | Ours |
The difference is not the detector
Three of the four rows above run axe-core, and ours is the same axe-core you can
npm install tonight. Nobody in this table detects a violation the
others cannot. What differs is what the tool does when it finds fifty-six of them
on a codebase that shipped years ago.
A threshold counts. It cannot tell a violation you fixed from one you introduced, so fix one and add one and the number is unchanged and the gate stays green. Ignoring an issue code is worse in the other direction: it silences that rule everywhere, including on the page you write tomorrow.
A baseline is a third thing. Every violation gets a fingerprint, the accepted ones are committed to your repository, and the gate fails on fingerprints that are not in the file. The fifty-seventh violation fails the build on the day it appears; the first fifty-six stay exactly as visible as they were, in a file you can read in a pull request.
You can build that on top of any of the tools above, and if the debt is small it is not worth buying. We think it is the whole problem, so it is the whole product.
When one of theirs is the right answer
- Your site already passes
-
Greenfield, or debt already paid down:
@axe-core/cli --exitin a workflow step is free and finished. There is nothing to baseline. - You want one number to watch
- Lighthouse CI, asserting on the accessibility category, alongside the performance budget you probably already have. A score is a poor gate and a decent trend.
- No third party may see your URLs
- Then a hosted scanner is the wrong shape and no argument fixes that. Pa11y CI or the axe CLI run entirely on your machines. Our privacy notice says what we would receive; if that list is one item too long, self-host.
- You would rather not depend on a small company
- Reasonable. Note that your baseline file is plain JSON in your repository, so the cost of leaving is reading a file you already have.
What you are actually buying
Not detection. A fleet of headless browsers somebody else keeps running, a baseline format with the diffing already written, adapters that scan pages behind a login, scheduled monitors, and reports with your client's logo on them. The pricing page says the same thing in fewer words: axe-core is free, and what you pay for is the fleet, the uptime, the integrations and the baseline machinery.
What is not in this table
Overlay widgets — the one-line script that promises to fix a site from the browser. They are not in the comparison because they are not the same category of thing, and because the claims made for them are the reason this industry is hard to buy in. Nothing on this page, ours included, makes a site accessible or compliant. What a scan does and does not tell you is the honest version, and the criteria no scanner detects is the list.