The three free tools most owners land on are WAVE, axe DevTools and Lighthouse. All three are good. None of them is a compliance verdict, two of them share an engine, and two of the three say so themselves in their own documentation, in words stronger than anything we would write for them.
The Three, Side by Side
| WAVE | axe DevTools | Lighthouse | |
|---|---|---|---|
| Made by | WebAIM | Deque | |
| Where it runs | Browser extension and a web version | Browser extension, in DevTools | Built into Chrome DevTools |
| Engine | WebAIM's own | axe-core | axe-core |
| How it reports | Icons drawn over your live page | A list in a DevTools panel | A score out of 100 plus a list |
| Best at | Seeing where a problem physically is | Precision, low false positives, dev workflow | Being already installed |
| Watch out for | Alerts are prompts to look, not failures | Only checks the page state on screen | The score invites false confidence |
| Can it test behind a login | Yes, in the extension, which runs locally | Yes, it runs in your own browser | Yes, it runs in your own browser |
WAVE, and Seeing It On the Page
WAVE's trick is that it does not hand you a list, it draws on your page. Icons appear exactly where each issue lives, so a missing form label shows up next to the field it belongs to. For a site owner rather than a developer, that is the fastest way to understand what a report is even talking about.
The extension is worth having for a second reason nobody mentions. It evaluates entirely inside your browser and sends nothing to WebAIM's server, so it can test pages behind a login, a staging environment, or something running on your own machine. If your whole product sits behind a sign-in, that is the difference between a usable tool and a useless one. Our own free scan cannot follow you in there, and neither can WAVE's web version.
Read its categories carefully, because there are more than two and the count that scares people most is its own. Errors are failures. Contrast Errors get their own top-level number, and it is usually the biggest one on the page, which is unsurprising given low contrast turns up on 83.9% of home pages at an average of 34 instances each. Alerts are things a human should look at and are frequently fine. A page showing thirty alerts is not necessarily worse than one showing three, and it may just have more images needing a judgment call. Treating alerts as failures is the commonest way people misread WAVE.
There is a fourth category, Features, which reports things that probably help. WebAIM hedges even that one, saying those should be verified too. So on WAVE's own account, none of the four categories is a verdict.
The maker's own warning
WebAIM states it plainly in WAVE's documentation. WAVE cannot tell you if your content is accessible, only a human can determine that, and the absence of errors does not mean your page is accessible or compliant. They go further and say they deliberately never indicate that a page has passed, and issue no badges or certificates. That is the organisation behind the best-known free scanner refusing to sell the thing every overlay vendor sells.
axe DevTools, and What Precision Costs
axe DevTools runs on axe-core, Deque's open-source rules engine, tuned to report almost no false positives. Deque's own wording is zero false positives, bugs notwithstanding, and that parenthesis is doing real work, so treat a violation as near-certain rather than certain. The reliability is why axe-core ended up inside so many other tools, Lighthouse included.
The same conservatism is its limit, and the mechanism is worth understanding. axe does not discard uncertain results, it routes them into a separate bucket called incomplete, meaning it started a check and could not decide. Text over a photograph lands there almost every time. Most reports show violations and drop the incomplete list, and the silence reads as a pass. It is not one.
One clause of honesty about the word free in this page's title. axe DevTools has a paid Pro tier alongside the free extension, so you will meet an upsell. The free tier does everything described here.
One practical trap applies to all three tools. They check the page as it currently sits. Your closed menu, your unopened modal and your untriggered error state are all invisible to the scan. Open the thing, then scan again.
Lighthouse, Already Installed and Easily Misread
Lighthouse is in Chrome DevTools right now, under the Lighthouse tab. Run it and you get an accessibility score out of 100 alongside performance and SEO.
It runs a subset of axe-core's rules, 68 audits against axe-core's 105. So a Lighthouse 100 means nothing failed among the rules it chose to run, on this one page, in this one state. That is a small slice of WCAG.
Worth knowing how the number is built, too. Each audit is pass or fail with no partial credit, and the score is a weighted average of those binary results, weighted by how much impact axe assigns each rule. Which is why a 99 and a 71 can describe pages with the same number of problems, and why chasing the number is a poor use of an afternoon.
Why the score is the problem
A 100 out of 100 feels like an ending. It is a green light on the mechanical checks and silence on everything else, and that silence covers most of WCAG. Google prints the caveat at the top of the accessibility section of every report you have ever run, saying automatic detection catches only a subset of issues and does not guarantee accessibility, and encouraging manual testing. Nobody reads it, because it sits above a big green number. We have audited plenty of sites scoring 100 where a keyboard user could not finish checkout.
What All Three Miss
They share a blind spot, and it is structural rather than a gap in any one product. None of them can tell you:
- Whether your alt text is true.
- Whether your link text means anything out of context.
- Whether focus order matches reading order. W3C publishes no automated rule for this at all.
- Whether an error message tells the user what to actually do. No rule for this one either.
- Whether your checkout can be completed by ear.
- Whether a heading marked as a heading is one.
Our automated versus manual guide works through why each of these resists automation, with the WCAG rule attached to each and the coverage numbers behind them.
Somebody Ran Ten Tools at a Page Built to Fail
WebAIM and Google each print a warning saying their tool cannot tell you whether a page is accessible. Neither warning puts a number on how much a tool misses, and no vendor has an incentive to publish one. In February 2017 a government team did, and it is still the closest thing to an independent benchmark anybody has.
The UK's Government Digital Service built a page carrying 143 known barriers across 19 categories, then ran ten automated tools at it. The best single tool found 41% of them, and that count is generous, because it includes prompts telling a human to go and look rather than confirmed detections. All ten together reached 71%. GDS's own recommendation off the back of it was to combine automated tool testing with manual checking, an accessibility audit and user testing.
Two caveats before you quote that at anybody, because both of them will come back at you otherwise. The study is from 2017 and every tool in it has moved since. And 71% is the half a vendor will read out, so say the rest of the sentence first. Nobody runs ten scanners, and even the aggregate left nearly three barriers in ten standing on a page whose entire purpose was to be caught.
Why Two Honest Tools Disagree
It is not that one of them is wrong. They are built on partly different rule sets, and you can count the difference. Our scan runs 63 WCAG-mapped checks and labels another 27 as best-practice checks rather than WCAG failures. A tool built on a different selection will disagree by construction, before anybody argues about thresholds.
Here is the disagreement you are most likely to hit in practice. Take an email field whose only labelling is placeholder text. The specification that computes accessible names accepts a placeholder as a fallback, so axe's label rule passes it, which means axe DevTools passes it, Lighthouse passes it and our scan passes it. WAVE reports it as an alert rather than an error. And a human auditor writes it up as a failure of Labels or Instructions, because a label that disappears the moment you type is not presented to everybody. That criterion has no automated rule anywhere. Four tools, three answers, one broken field, and every one of them behaving correctly.
How We would Use Them
- Lighthouse for a thirty-second temperature check, since it is already open and costs you nothing to run.
- WAVE when you want to understand a problem, because seeing it drawn on the page beats reading about it in a list.
- axe DevTools when a developer is fixing things and needs precision without noise. Read the incomplete list, not just the violations.
- Then a person, for the judgment calls none of the three covers, which is most of the standard.
One thing not to do with any of them. If a report tells you something is wrong, do not reach for ARIA as the fix. WebAIM's survey of a million home pages found that pages using ARIA averaged 59.1 detected errors against 42 for pages without it. That does not prove ARIA causes failures, since complicated applications use more of everything. It does kill the instinct that adding attributes is how you clean up a scanner report.
One honest limit
Our own free 10-page scan has this same ceiling. It runs your site in a real browser across ten pages instead of one, lists the checks it could not decide, and names the source rule behind every finding, and it is still automated evidence rather than a conformance verdict. We say what it cannot see on its own page, because a tool that oversells itself is the thing we are arguing against.