What is axe-core and Why It Powers Real Accessibility Audits

If you've looked at any professional accessibility tool — Deque's axe DevTools, Microsoft's Accessibility Insights, Google's Lighthouse, WAVE's engine, or AccessProof — you've already touched axe-core. It's the open-source rules engine that quietly powers most evidence-based audits today. Here's what it actually does, why it's the standard, and how it compares to the “AI accessibility” overlay claims you've probably seen.

What axe-core is

axe-core is an MIT-licensed accessibility testing engine maintained by Deque Systems. It runs in any environment that has a DOM — browsers, headless Chromium, Node — and returns a structured list of accessibility violations, each tied to a specific WCAG success criterion and DOM node.

The source lives at github.com/dequelabs/axe-core. It ships rules for WCAG 2.0, 2.1, 2.2 (Level A, AA, AAA), plus Section 508 and best-practice checks. As of axe-core 4.9 (released 2024), the engine implements approximately 90 individual rules.

What it actually checks

axe-core works by walking the rendered DOM and evaluating each node against its rule set. Each rule produces one of four outcomes:

• Violations: definitively fails a WCAG criterion (e.g. color-contrast, label, button-name).
• Needs review: cannot be determined automatically; flagged for manual review.
• Passes: rule was checked and the node passed.
• Inapplicable: the rule doesn't apply (e.g. no images on the page → no alt-text rule fires).

Examples of categories axe-core reliably catches:

• Color contrast against computed background (including against background images via canvas sampling).
• Missing or incorrect ARIA attributes and roles.
• Form fields without programmatic labels.
• Buttons and links without accessible names.
• Heading structure and landmark misuse.
• Keyboard traps detectable from static DOM analysis.
• WCAG 2.2 target size (Success Criterion 2.5.8).

And the categories it deliberately doesn't cover (these need humans):

• Whether alt text is meaningful (it can only check presence/absence).
• Whether headings describe the section they precede.
• Reading order in complex visual layouts.
• Whether a control's name is appropriate to its function.
• Live region behavior over time.

This honesty about scope is exactly why axe-core became the trust anchor of the industry. Deque publicly documents that fully automated testing can catch a meaningful share of issues, but the precise share depends on the site. Some sites have mostly automatable issues (forms, content); others rely heavily on custom widgets where manual review is essential. axe-core scopes the half it can handle — accurately — instead of overclaiming.

Why “AI accessibility” overlays don't replace it

Overlay widgets (accessiBe, UserWay, AudioEye) promise to “fix” accessibility by injecting JavaScript that mutates the page at runtime. The promise sounds appealing; the practical issues are well documented:

• Overlays operate downstream of the underlying HTML/CSS. They can't fix a button that has no semantic role; they can only paper over it. Screen readers can still expose the broken markup beneath.
• The Overlay Fact Sheet — signed by 800+ accessibility professionals including the authors of axe-core — lists technical reasons overlays often introduce new issues (keyboard focus stealing, ARIA conflicts, autoplay sounds).
• Courts have allowed lawsuits to proceed against sites that installed an overlay as their primary remediation. The widget's presence is not a defense.
• Most overlays don't produce an auditable, dated report of what they fixed. Plaintiff counsel asks for one. You don't have it.

The alternative is to measure the underlying site — axe-core's job — and fix what's actually broken in the source code. See our side-by-side comparison vs. overlay vendors.

How AccessProof uses axe-core

We vendor axe-core 4.9.1 — the version is pinned, the file is shipped with our scanner image, and we don't fetch it from a CDN at scan time. This matters because:

• Reproducibility: the same scan today and 6 months from now uses the same engine version. The deltas in your reports reflect changes to your site, not engine drift.
• CSP-friendly: vendoring lets us run axe-core inside a headless Chromium even on sites with strict Content Security Policies that would block an external CDN script.
• Auditable: anyone inspecting a PDF report can verify which axe-core version produced it.

We run axe-core with the wcag2a, wcag2aa, wcag21a, wcag21aa, wcag22aa rule sets enabled, then translate the violation list into a scored report (critical / serious / moderate / minor), and render it to a dated PDF. The PDF is the artifact you keep in your remediation log.

Want to see a real one? Run a free scan — no signup needed for the first one.

How to interpret axe-core impact levels

Each violation comes with an impact level: critical, serious, moderate, or minor. These are not WCAG-defined — Deque assigns them based on user impact severity. A rough mapping:

• Critical: blocks a user from completing core tasks (missing button label, keyboard trap, empty links).
• Serious: degrades the experience significantly (insufficient contrast, missing form labels).
• Moderate: noticeable but not blocking (ARIA attribute on wrong element, redundant landmarks).
• Minor: edge case or convention (page region missing).

For triage, fix critical and serious before anything else. AccessProof's scoring algorithm weights them critical × 4 + serious × 2 + moderate × 1 + minor × 0.5 on a 100-point scale — the same weighting Deque suggests in its documentation.

The other engines, briefly

• WAVE (WebAIM) is an excellent rules engine in its own right, with a strong visual UI. We've found it slightly more lenient on color contrast edge cases than axe-core but generally aligned on critical violations.
• Lighthouse's accessibility category uses axe-core under the hood but runs a curated subset. Treat the Lighthouse score as a starting indicator, not an audit.
• Accessibility Insights (Microsoft) also uses axe-core, paired with an assisted manual test workflow. Recommended for in-team adoption.

How widely it's actually used

axe-core sits inside the accessibility tooling of many of the largest software organizations. Some confirmed integrations:

• Google Lighthouse uses a curated axe-core rule subset in its Accessibility category.
• Microsoft Accessibility Insights (web and desktop) is built on axe-core with manual-assist workflows added on top.
• Deque axe DevTools, both the free browser extension and the paid enterprise products, all run the same axe-core engine.
• Salesforce, IBM, GitHub, and many other major SaaS vendors use it in CI per public talks and engineering posts.
• Web framework starter kits and accessibility linters (eslint-plugin-jsx-a11y, etc.) frequently cite axe-core's rule definitions as their reference.

Open-source rules engines benefit from network effects: the more eyes on the rules, the faster false positives are caught and the faster new WCAG criteria get covered. Closed engines invariably trail.

How axe-core decides what is a violation

Each axe-core rule is a function that runs against a node and returns pass/fail/needs-review. The rules are versioned in the GitHub repo and discussed openly in issues and PRs. When the W3C publishes a new WCAG version, Deque maintainers and community contributors implement supporting rules — that's how WCAG 2.2 support landed in axe-core 4.8 and 4.9.

For a concrete example, here's the kind of result axe-core produces for a single contrast violation:

{
  "id": "color-contrast",
  "impact": "serious",
  "tags": ["cat.color", "wcag2aa", "wcag143"],
  "description": "Ensures the contrast between foreground and background colors meets WCAG 2 AA contrast ratio thresholds",
  "nodes": [{
    "target": ["#hero p.subtitle"],
    "html": "Get started in 60 seconds
",
    "failureSummary": "Element has insufficient color contrast of 3.21 (foreground color: #9ca3af, background color: #ffffff, font size: 14.0pt, font weight: normal). Expected contrast ratio of 4.5:1"
  }]
}

That single record gives you the rule, the WCAG mapping, the impact level, the exact CSS selector, the computed ratio, the colors involved, the font size, and the threshold it failed against. This level of specificity is what makes axe-core useful for engineers and credible in audit reports — the “evidence” is right there in the artifact.

What it costs to use directly

axe-core is MIT-licensed and free. If you're comfortable with Node and Playwright/Puppeteer, you can integrate it into your CI in an afternoon:

npm install @axe-core/playwright
// in a Playwright test
const accessibilityScanResults = await new AxeBuilder({ page })
  .withTags(['wcag2a', 'wcag2aa', 'wcag21aa', 'wcag22aa'])
  .analyze();
expect(accessibilityScanResults.violations).toEqual([]);

What you don't get out of the box: scheduling, history, scoring, PDF export, multi-page crawl, evidence retention. That's the layer hosted services like AccessProof add on top. The engine itself is identical; the operational glue is where vendors differ.

Versioning and the audit-trail question

Because axe-core evolves — new rules ship, existing rules get stricter — anyone who keeps long-term audit history should record which version produced each report. A 2024 PDF that says “axe-core 4.9.1” in the footer is reproducible: you can re-run the same version against an archived copy of your site and get the same answer.

Vendors that hide their engine version (or use a custom unpublished rule set) make this kind of reproducibility impossible. Ask for the version in every PDF or HTML report your tool generates. AccessProof prints it on every page.

Summary

axe-core is the rules engine that turns “accessibility” from a vague aspiration into a measurable set of pass/fail checks. It's open source, transparent about what it can't check, and used by the people who set the standard. If your accessibility tool isn't built on it (or one of the open engines with comparable transparency), ask what it's built on — and what its false positive rate is on your stack.

AccessProof uses axe-core because the alternative — running our own opaque scorer or, worse, an overlay — wouldn't produce evidence anyone could trust. See pricing if you'd like to add scheduled, dated, axe-core-backed audits to your remediation log.

---

Originally published on access-proof.com.