Definition: axe-core is an open-source library from Deque Systems that tests web pages for accessibility automatically, in the browser. It contains rules for WCAG Levels A, AA and AAA and for best practice, and is licensed under the Mozilla Public License 2.0 [1]. Many testing tools are built on it, Reviseberg included.
German: axe-core · Also: axe · Last reviewed: 27 September 2026
How it works
axe-core is JavaScript that runs inside the loaded page. It therefore tests the finished DOM, after the page's own scripts have run – what the browser and a screen reader actually get. Each rule checks one thing and has its own ID, such as image-alt (image without alt text), color-contrast (text contrast), label (form field without a label) or button-name (button without a name) [3].
It is used in browser extensions, in automated tests with Playwright or Puppeteer, and in build pipelines. Deque also sells commercial products built on it.
Tags: which rule belongs to which standard
Every rule carries tags [2]. wcag2a and wcag2aa mean WCAG 2.0 Level A and AA, wcag21a and wcag21aa WCAG 2.1, and wcag22aa WCAG 2.2 Level AA. A second tag names the criterion, such as wcag143 for 1.4.3. Rules tagged best-practice point to no success criterion; they describe good practice. Rules tagged experimental are switched off by default.
Four kinds of result
- violations: the rule found a failure.
- passes: the rule was met.
- incomplete: the rule could not decide – contrast of text over an image, for example – and a person has to check.
- inapplicable: nothing on the page matched the rule.
"Incomplete" is the one that matters. A tool that drops these results shows a page as clean when it could not actually judge it.
In code
import AxeBuilder from '@axe-core/playwright'
const results = await new AxeBuilder({ page })
.withTags(['wcag2a', 'wcag2aa', 'wcag21a',
'wcag21aa', 'wcag22aa'])
.analyze()
console.log(results.violations.length)
console.log(results.incomplete.length)
What axe-core cannot do
axe-core presses no keys, so it cannot find a keyboard trap or an illogical focus order. It sees that alt text is missing, not whether it is right. It tests the page in the state it is in when it runs – a menu that only opens on a click stays untested unless something opens it. Only a minority of WCAG criteria can be fully decided this way [4], which is why zero violations does not mean accessible.
How Reviseberg handles it
On every crawled page, at 1280 px wide, Reviseberg runs axe-core's rules for WCAG 2.0, 2.1 and 2.2 at Levels A and AA, plus its best-practice rules. The rules color-contrast, target-size, meta-viewport and scrollable-region-focusable run again at 360 px. Findings are mapped to WCAG 2.2 criteria and to chapter 9 of EN 301 549. "Incomplete" results go to a separate list of potential issues and never count as a pass. Since 27 September 2026, Reviseberg shows best-practice rules such as region, heading-order, landmark-one-main and page-has-heading-one as "best practice, no WCAG criterion": they carry a small weight in the score and can never fail a criterion. Part of what axe cannot do is covered by the keyboard agent, which walks a user journey with real key presses.
Related terms
Automated accessibility testing · Manual accessibility testing · Keyboard trap · Contrast ratio · Accessibility overlay · WCAG