Accessibility
axe-core: uses, strengths, and limitations
Automated accessibility rules for web interfaces.
- Pricing model
- Open source
- Open source
- Yes
- Last verified
In simple terms
What is axe-core?
axe-core is an accessibility rules engine for HTML interfaces. It detects many machine-testable accessibility problems and integrates with browsers and test frameworks.
Practical guide
axe-core explained simply
In plain words
axe-core reads a web page the way assistive technology would and reports problems it can detect mechanically: a button with no label, text that is too faint to read, a form field nothing describes. It is the accessibility check you can run in seconds, on every build.
It is also the engine inside many other accessibility tools, including several browser extensions you may already have used.
What using it looks like
import { test, expect } from '@playwright/test';import AxeBuilder from '@axe-core/playwright'; test('the checkout page has no detectable violations', async ({ page }) => { await page.goto('/checkout'); const results = await new AxeBuilder({ page }).analyze(); expect(results.violations).toEqual([]);});Six lines added to an existing test, and every future change to that page gets checked. This is the highest-value accessibility work most teams can do in an afternoon.
What to watch out for
- Never report "zero violations" as "accessible". Report it as "no automatically detectable violations".
- Disabling a rule to make the build green hides a real barrier. If you must, write down why and when you will revisit it.
- Run it on real page states — logged in, with errors showing, with the menu open — not just the empty landing page.
- Someone has to own fixing what it finds, or the results become noise people scroll past.
Common questions
Is axe-core free?
Yes, the engine is open source. Deque sells commercial tools built on top of it.
Does passing axe mean we meet WCAG?
No. It checks the subset of criteria that can be tested mechanically. Conformance needs human evaluation as well.
Where should we run it?
All three places, ideally: a browser extension while developing, an automated check in CI, and a periodic manual review for what neither can catch.
Core capabilities
What it helps teams do
Rules engine
Evaluate supported WCAG-related rules and accessibility best practices.
Integration
Embed checks in browser tools, automated tests, and development workflows.
Targeted scans
Include or exclude relevant interface regions when a full-page scan is unsuitable.
Machine-readable results
Return violations, affected nodes, and remediation context for reporting.
Good fit
Consider axe-core when
- Automated accessibility checks in development and CI
- Finding repeatable rule violations early
- Combining accessibility rules with functional tests
Consider alternatives
Another approach may fit when
- The expectation is complete WCAG conformance from automation alone
- Native mobile accessibility is the only scope
- The team has no process for reviewing and fixing reported findings
Trade-offs
Limitations to understand
- Automated rules can detect only part of accessibility conformance.
- Usability, meaningful alternatives, and assistive-technology experience still require human evaluation.
- Rule configuration and exclusions can hide important issues if used carelessly.
Evaluation checklist
Questions to answer before adoption
- 01Which WCAG target and organizational policy apply?
- 02Where will scans run in the development lifecycle?
- 03Who reviews issues that require human judgment?
- 04How will exclusions be documented and revisited?