axe-core

Visit Website

Introduction

axe-core is a JavaScript library that runs accessibility rules against a page or an HTML fragment and returns violations, incomplete checks, and passes. Deque maintains it at dequelabs/axe-core under the Mozilla Public License 2.0. Integrations embed the same engine in Playwright, Cypress, Selenium, Jest, React, Vue, and the browser. The library does not crawl a site and it does not file tickets. It inspects the DOM you hand it.

Deque’s paid products, axe DevTools and axe Monitor, use this engine and add a browser extension, guided tests, and organization reporting. Those products are not this library. Automated rules do not cover every WCAG success criterion. axe-core finds the ones a program can decide; keyboard traps, meaning, and many cognitive issues still need a person.

Features

1. Rule set: Rules map to WCAG 2.x success criteria and a few best-practice checks. Each violation names the rule id, impact, nodes, and a help URL.
2. axe.run: In a browser context you call axe.run() on document or a subtree and receive a results object. Tags filter the run (wcag2a, wcag2aa, best-practice).
3. Integrations: @axe-core/playwright, @axe-core/puppeteer, cypress-axe, jest-axe, and react-axe wrap the same engine. Selenium uses the injected script via @axe-core/webdriverjs or the CLI.
4. CLI: @axe-core/cli loads a URL in a headless browser and prints results. It is a separate package from the library.
5. Incomplete results: Some checks return incomplete when the engine cannot decide (for example contrast on a background image). Those are not passes.
6. Configuration: You can disable rules, set a reporter, and exclude selectors (third-party widgets, for instance).
7. Shadow DOM and iframes: The engine can enter open shadow roots and same-origin frames. Cross-origin frames stay out of reach.
8. Versioned rules: Rule behavior changes between releases. Pin the version in CI so a Monday morning failure is a code change or a deliberate upgrade, not both at once.

Pros

1. The engine is the common one: Playwright, Cypress, and Storybook accessibility checks that say “axe” are usually this library. Results are comparable across runners.
2. JSON you can fail a build on: violations.length === 0 is a clear gate. The node target tells you which element failed.
3. Free to embed: MPL-2.0. You can ship it inside a test suite or a product build. File-level copyleft applies if you modify axe-core itself.
4. Actively updated rules: Deque publishes rule changes in the library changelog, which is the list your suite will start failing on.
5. Subtree runs: Component tests can axe a single container instead of a whole marketing page.

Cons

1. Partial coverage: A clean axe run is not a WCAG conformance claim. Deque’s own docs describe automated checks as a subset of what an audit covers.
2. Needs a DOM: Calling the library from Node without a browser or jsdom does nothing useful. The page also has to be in the state you mean to test, after client-side rendering.
3. Incomplete is easy to ignore: Teams assert on violations and drop incomplete. Some real issues sit in that bucket.
4. Noise from third parties: Cookie banners and embedded widgets fail rules you do not own. Excluding them hides your own bugs if the selector is too broad.
5. Commercial tooling is separate: Saved scans, guided manual tests, and org-wide dashboards are axe DevTools or Monitor, not npm install axe-core.

Usage and Links (Example)

Playwright, after the page has rendered:

npm install --save-dev @axe-core/playwright

const AxeBuilder = require("@axe-core/playwright").default;

test("home has no axe violations", async ({ page }) => {
  await page.goto("https://example.com");
  const results = await new AxeBuilder({ page }).analyze();
  expect(results.violations).toEqual([]);
});

The same engine from a page that already loaded the script:

const results = await axe.run(document, { runOnly: ["wcag2a", "wcag2aa"] });

Resources:

• axe-core on GitHub
• Rule descriptions
• Deque axe DevTools (commercial; not this library)

Pricing

1. Free: axe-core is MPL-2.0. The npm package and the GitHub repo have no license fee.
2. axe DevTools and Monitor are paid: Deque sells a browser extension, CI integrations with extra workflow, and a monitoring product. Those prices are on deque.com and are not required to run the engine in your own tests.
3. CI time: A full-page axe.run is usually cheap next to the browser startup around it.

Recommended for?

1. Playwright, Cypress, and Selenium suites that should fail on detectable WCAG issues before a human audit.
2. Component tests that can render a subtree and assert violations is empty.
3. Design systems that want one rule pack shared by Storybook and end-to-end tests.
4. Teams who will still do manual checks for keyboard behavior, focus order, and content that a rule cannot judge.

Conclusion

axe-core is the accessibility engine to embed when you want reproducible, versioned WCAG checks in the tests you already run. Treat a green run as “no violations in this rule set,” not as a finished audit. Pin the version, assert on violations, and read the incomplete list. Buy Deque’s hosted tools only if you need the extension workflow or org reporting on top of the same rules.