Tools

axe-core

Also: axe

An open-source automated accessibility testing engine from Deque, used by browser extensions (axe DevTools, Accessibility Insights), CI scripts, and Lighthouse. Catches an estimated 30–40% of WCAG issues.

axe-core is the open-source automated accessibility testing engine developed by Deque Systems. It powers a wide ecosystem of testing tools — browser extensions (axe DevTools, Accessibility Insights), CI scripts (axe-cli, jest-axe, cypress-axe, playwright-axe), and most notably Lighthouse’s accessibility audit.

For the past decade, axe-core has been the most-deployed automated accessibility checker on earth. Most accessibility-related CI pipelines in production today are running axe-core under the hood, often without the team realising it.

What axe-core does well

axe-core’s rule set is conservative by design: a rule is included only when its false-positive rate is essentially zero. That makes axe-core reliable as a CI gate — when it flags a violation, the violation is real, and the team can act on it without worrying about whack-a-mole on flaky checks.

Rules axe-core catches reliably include:

  • Missing or empty labels on form controls.
  • Missing alt attributes (and obviously-junk alt like filenames).
  • Insufficient colour contrast (text and UI components).
  • Invalid ARIA — non-existent roles, missing required properties, forbidden child structures.
  • Duplicate IDs that break ARIA references.
  • Missing language attribute on <html>.
  • Buttons with no accessible name.
  • Form fields with no programmatic label.
  • Empty links (<a href>...</a> with no text or alt).
  • Heading-level skips and missing <h1> in some configurations.

That list covers a meaningful percentage of low-hanging accessibility failures. Running axe-core in CI catches them at code-review time rather than at audit time.

The ceiling

axe-core’s authors are explicit about the ceiling: automated tools can detect at most 30–40 % of WCAG issues. The rest require human judgment and assistive-technology testing.

Specifically, axe-core cannot catch:

  • Incorrect alt text — it can tell you alt is missing, but not that alt="hamburger icon" is wrong for a button that opens a menu.
  • Misleading link text — “Click here” links are spec-correct, just useless to screen-reader users.
  • Broken focus order — tab order that doesn’t match visual order is a 2.4.3 failure that no static checker can detect.
  • Incorrect heading structure — axe-core catches missing h1 and level skips, but can’t tell that a page has used h2 for what should have been h1.
  • Content that only works for certain user groups — accessible to WCAG but unusable for low-vision users, cognitive-disability users, etc.

A site that scores zero violations in axe-core is necessary for accessibility but not sufficient. The remaining work — focus order, content quality, screen-reader behaviour, real-user testing — is what takes most of the actual time.

How to use axe-core operationally

Three deployment patterns work well together:

  1. In the editor. axe DevTools and Accessibility Insights run on demand against the rendered DOM in a browser tab. Use during development.
  2. In CI. axe-cli, jest-axe, cypress-axe, or playwright-axe fail the build on new violations. Use to prevent regressions.
  3. At audit time. External auditors run axe-core as a starting point, then layer manual testing on top. Use to validate the automated baseline.

The combination keeps automated-detectable issues at zero while a real accessibility programme handles the rest.