axe-core vs. Lighthouse vs. WAVE: what actually differs

Published July 2026.

Three tools come up in nearly every "how do I test accessibility" conversation: axe-core, Google Lighthouse, and WAVE. They're not interchangeable, and the differences matter more than most comparisons admit — including this one, since Gangway runs axe-core under the hood and has a stake in the answer.

They're not three independent engines

axe-core is a rules engine, not a standalone product — it's open source, maintained by Deque, and embedded inside a large share of the automated testing ecosystem. Lighthouse's accessibility category runs a subset of axe-core's rules alongside its performance/SEO/best-practices checks, so "Lighthouse accessibility score" is really "a partial axe-core run, bundled with unrelated audits." WAVE is the odd one out: a separate rules implementation, not axe-core underneath, which is part of why its results diverge from the other two.

Where they actually differ

• Rule coverage. axe DevTools/axe-core runs the full rule set; Lighthouse runs a deliberately narrower subset, so a page can score well in Lighthouse while axe-core (or Gangway) surfaces issues Lighthouse's subset doesn't check for.
• False positives. axe-core is built to minimize false positives — Deque's stated design goal is that if axe flags something, it's a real issue, not a maybe. WAVE takes the opposite trade-off on purpose: it over-reports, surfacing "alerts" that aren't WCAG failures but flag things worth a human look. That makes WAVE noisier but useful for a manual audit pass where a person is going to review every flag anyway — and a worse fit for automated CI gating, where noisy failures get ignored or the check gets disabled.
• What "clean" means. An axe-core pass with zero violations still includes an "incomplete" bucket — checks that need a human to confirm one way or the other. A clean scan across all three tools is not the same claim as "this page is accessible"; it's "these specific automated checks didn't fail."

The ceiling that applies to all three

Independent estimates put the share of WCAG success criteria that any automated tool can reliably evaluate at roughly 30-40%; axe-core's own published estimate for its rule set is around the upper end of that range. That ceiling isn't a gap one tool closes and another doesn't — it's structural. None of the three can tell you whether alt text is accurate, whether a custom widget is usable with a screen reader, or whether your focus order makes sense to someone tabbing through by keyboard. That's true of axe-core, Lighthouse, and WAVE equally, and it's why Gangway's own testing-honesty post makes the same point about itself.

A reasonable default, not a verdict

Run axe-core (or a tool built on it, like Gangway) on every page, every change — it's the most precise engine of the three and the cheapest to run continuously. Use WAVE for a manual audit pass, where a person is deliberately reviewing every flagged item and the extra noise is the point, not a bug. Treat a clean Lighthouse accessibility score as a weak positive signal at best — it's checking a subset, alongside three unrelated categories, and was never built to be the accessibility source of truth.

None of the three, alone or combined, replaces a keyboard walkthrough or a screen-reader pass on the flows that actually matter to your users. That's the same "good-faith effort, documented honestly" model this blog keeps coming back to — the scanner is the first pass, not the finish line.

See how Gangway's scan → fix → verify workflow works or start a 14-day trial.