Testing & Tools

axe-core Explained: The Industry-Standard Accessibility Testing Engine

axe-core is an open-source accessibility testing engine, originally built by Deque Systems, that has become the de facto industry standard rules engine behind most modern automated accessibility tools — including browser extensions, CI/CD test integrations, and commercial scanning platforms like AllyProof.

The design principle that sets it apart: zero false positives

axe-core was deliberately engineered around a "zero false positives" philosophy — every rule is designed so that a reported violation is a genuine, confirmed WCAG failure, not a maybe. Where a check would require judgment calls that risk false positives (is this heading actually descriptive enough?), axe-core either omits the rule entirely or reports it as incomplete (needs human review) rather than as a confirmed violation. This is a meaningfully different design choice than tools that flag anything remotely suspicious and let the user sort out what's real — it trades some coverage for reliability.

The four result buckets axe-core produces

Bucket	Meaning
violations	Confirmed failures — reliable, actionable
incomplete	Couldn't determine automatically — needs human review
passes	Confirmed passing checks
inapplicable	The rule didn't apply (no matching elements on the page)

What axe-core actually covers

axe-core ships with roughly 90+ rules covering WCAG 2.0/2.1/2.2 at A and AA, plus a separate set of "best practice" rules that check good conventions beyond what WCAG strictly requires (and which should always be labeled distinctly from actual WCAG violations, never conflated with them). Rules are tagged by which WCAG version and level they map to (wcag2a, wcag2aa, wcag21aa, wcag22aa, etc.) — critically, these tags are not cumulative: requesting only the wcag22aa tag returns just the criteria newly added in 2.2, not everything inherited from earlier versions, so a correct scan configuration has to explicitly request every relevant ancestor tag.

What axe-core alone doesn't cover

Consistent with the automated-vs-manual split generally, axe-core's own documentation is explicit that it detects roughly 30-40% of WCAG issues by criteria count (and a higher share by real-world issue volume, since the automatable criteria tend to be the most commonly-occurring ones). It's a foundational, highly reliable layer — not a complete accessibility testing solution on its own.

Why it's the right default choice for a scanning product

Given the choice between a tool that flags more issues with some false positives, versus one that flags fewer issues with high confidence in every one, the zero-false-positive design is the safer foundation to build a compliance-facing product on — a false positive erodes trust in every other finding a tool reports, while a true negative (a real issue the automatable ruleset genuinely can't catch) is addressed by pairing axe-core with complementary tools and manual review, not by loosening its own detection confidence.

Common questions

What is axe-core?

An open-source accessibility testing engine built by Deque Systems, now the de facto industry-standard rules engine behind most browser extensions, CI integrations, and commercial scanners, including AllyProof.

Why does axe-core have zero false positives?

It is deliberately engineered so every reported violation is a genuine WCAG failure. Where a check would require judgment, it reports the item as `incomplete` for human review rather than as a confirmed violation.

What does axe-core cover?

Around 90+ rules mapping to WCAG 2.0/2.1/2.2 at A and AA, plus separate best-practice rules. Its version tags are not cumulative, so a correct scan must request every relevant ancestor tag. It detects roughly 30-40% of WCAG issues by criteria count.