Testland
Browse all skills & agents

axe-a11y

Authors and runs axe-core accessibility scans - the most-deployed open-source a11y engine - via the `axe.run()` JavaScript API or the @axe-core/playwright / @axe-core/cli wrappers, parses the `violations[]` results into per-rule severity (critical / serious / moderate / minor), configures rule disable / disable-by-tag patterns, and emits JUnit-shaped output for CI gating. Use when the project ships UI tests in JavaScript / TypeScript and wants automated a11y coverage on every PR.

Install with skills.sh (any agent)

npx skills add testland/qa --skill axe-a11y
View source

axe-a11y

Overview

axe-core is "an accessibility testing engine for websites and other HTML-based user interfaces" maintained by Deque (axe-core (opens in new window)). It identifies approximately 57% of WCAG issues automatically and flags items requiring human review as "incomplete" (axe-core (opens in new window)).

The integration shape: load the engine into a page (via test fixture, browser extension, or framework adapter), call axe.run(), and parse the violations[] array.

When to use

  • The project ships JavaScript / TypeScript UI tests (Playwright / Cypress / Jest / Vitest).
  • Automated a11y coverage on every PR is a goal.
  • The team values WCAG SC tagging - axe rules map cleanly to WCAG 2.0 / 2.1 / 2.2 SCs.
  • Pair with a11y-violation-gate for the ratchet pattern over baseline.

If the team is on a non-JS stack, evaluate pa11y-a11y (CLI; uses axe-core under the hood), lighthouse-a11y (CI-friendly, broader perf + a11y), or ibm-equal-access-a11y.

Install

npm install --save-dev axe-core

(Per axe-core (opens in new window).)

For framework integration (preferred over raw axe.run()):

PackageWhen to use
@axe-core/playwrightPlaywright tests.
@axe-core/reactReact-component scans during rendering.
@axe-core/cliHeadless CLI for arbitrary URLs.
axe-core/api/install (raw)Custom integrations.

Authoring scans

Raw axe.run() API

import axe from 'axe-core';

axe.run()
  .then(results => {
    if (results.violations.length) {
      console.error('a11y violations:', results.violations);
    }
  })
  .catch(err => {
    console.error('axe error:', err.message);
  });

(Adapted from axe-core (opens in new window).)

For test environments where loading axe via <script> is easier:

<script src="node_modules/axe-core/axe.min.js"></script>

Playwright integration

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('checkout page passes axe scan', async ({ page }) => {
  await page.goto('/checkout');

  const accessibilityScanResults = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag22aa'])     // limit to AA
    .analyze();

  expect(accessibilityScanResults.violations).toEqual([]);
});

Cypress integration

// cypress/support/commands.js
import 'cypress-axe';

// In a test
cy.visit('/checkout');
cy.injectAxe();
cy.checkA11y();

How to use

  1. Install axe-core plus the framework wrapper (@axe-core/playwright for Playwright; cypress-axe for Cypress).
  2. Add one scan test per page or flow, and drive the page into the state you want scanned first (open modals, expand menus, submit forms) before calling axe.
  3. Pin the conformance target with .withTags([...]) (e.g. wcag2a, wcag2aa, wcag22aa), then .analyze().
  4. Suppress known false positives narrowly with .disableRules([...]) or .exclude(selector), each with an inline reason.
  5. Persist the raw accessibilityScanResults JSON as a CI artifact.
  6. Feed that JSON to a11y-violation-gate for the ratchet gate instead of asserting violations.length === 0.
  7. Route incomplete items to periodic manual screen-reader review (per screen-reader-test-author).

Results structure and rule configuration

axe.run() resolves to violations / incomplete / passes / inapplicable arrays; each violation carries id, impact, tags, and a nodes[] array of failing selectors. Rules are selected by WCAG tag (withTags) and suppressed by rule id or selector (disableRules / exclude). Full field tables, tag sets, and jq triage: references/results-and-config.md.

Worked example

A Playwright suite adds checkout.a11y.spec.ts. The test navigates to /checkout, runs new AxeBuilder({ page }).withTags(['wcag2a','wcag2aa','wcag22aa']).analyze(), and writes the result JSON to axe-results.json.

The run returns one entry in violations[]: id: color-contrast, impact: serious, tags including wcag2aa, and one node targeting button.primary with a failureSummary.

jq -r '.violations[] | "\(.impact): \(.id)"' axe-results.json prints serious: color-contrast. Piping the JSON to a11y-violation-gate compares it against the baseline: because this rule/selector pair is new, the gate fails the PR with the failing selector attributed. Fixing the button's foreground colour clears it, and the next run reports violations: [].

CI integration

# .github/workflows/a11y.yml
name: a11y

on:
  pull_request:
  push:
    branches: [main]

jobs:
  axe:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v5

      - uses: actions/setup-node@v4
        with:
          node-version: '20'

      - run: npm ci
      - run: npx playwright install --with-deps

      - name: Run a11y tests
        run: npx playwright test tests/a11y/

      - name: Upload report
        if: always()
        uses: actions/upload-artifact@v4
        with:
          name: a11y-results
          path: playwright-report/
          retention-days: 14

For richer reporting, persist the raw accessibilityScanResults JSON as a build artifact and pipe to a11y-violation-gate.

Anti-patterns

Anti-patternWhy it failsFix
Asserting violations.length === 0Existing legacy debt blocks every PR.Use the ratchet pattern via a11y-violation-gate.
Disabling rules without comment in codeReviewer can't tell which rules are intentionally off vs. forgotten.Inline comment explaining why; quarterly review.
Scanning only the homepageMost a11y bugs hide in less-traveled flows.Scan a representative URL set: home + 1 logged-in dashboard + 1 form-heavy + 1 long-content.
Running axe in productionPerformance overhead; possible info leak via verbose error logging.CI / staging only.
Treating incomplete as passItems needing human review go unreviewed; defects escape.Track incomplete separately; manual review per quarter.
One mega-test that runs axe across every pageOne failure = whole test fails; remediation hard.One axe test per page; failure attribution clear.

Limitations

  • Catches ~57% of WCAG issues (axe-core (opens in new window)) - the rest require manual screen-reader testing (per screen-reader-test-author).
  • Rule false positives. Rare but real; disableRules / exclude are escape hatches with documented rationale.
  • Doesn't cover dynamic state changes well. A modal that opens after user interaction won't be scanned unless the test triggers the open before calling axe.run().

References

  • axe-core (opens in new window) - main repo: install, axe.run(), results structure.
  • references/results-and-config.md - results arrays, violation fields, tag sets, disable / exclude.
  • Deque rule documentation - https://dequeuniversity.com/rules/axe/
  • @axe-core/playwright - https://github.com/dequelabs/axe-core-npm/tree/master/packages/playwright
  • W3C WCAG 2.2 - https://www.w3.org/TR/WCAG22/
  • a11y-violation-gate - CI gate using axe results.
  • pa11y-a11y, lighthouse-a11y, wave-a11y, ibm-equal-access-a11y - alternative scanners.

axe-core results structure and rule configuration

View source (opens in new window)

axe-core results structure and rule configuration

Results structure

axe.run() resolves to an object with four arrays (axe-core (opens in new window)):

FieldMeaning
violationsDefinite issues - block this in CI.
incompleteItems needing human review (axe couldn't determine).
passesSuccessful checks.
inapplicableRules that don't apply to this page.

Each violation has:

FieldMeaning
idRule ID (e.g. color-contrast, label, aria-required-attr).
impactcritical / serious / moderate / minor.
tagsIncludes wcag2a, wcag22aa, etc. - for severity-by-SC tagging.
descriptionOne-line explanation.
helpLonger remediation guidance.
helpUrlDirect link to Deque's rule documentation.
nodesArray of failing elements with target (selector), html, failureSummary.

Triage with jq:

# Top violations by impact
jq -r '.violations[] | "\(.impact): \(.id) - \(.description)"' axe-results.json

# Just the failing selectors per rule
jq -r '.violations[] | "\(.id):", (.nodes[].target | tostring)' axe-results.json

Rule configuration

By tags

axe ships rules tagged with conformance levels:

new AxeBuilder({ page }).withTags(['wcag2a', 'wcag2aa', 'wcag22aa'])

Common tag sets:

Tag setCoverage
['wcag2a', 'wcag2aa']WCAG 2.0/2.1 A + AA. Default for most teams.
['wcag2a', 'wcag2aa', 'wcag22aa']Adds WCAG 2.2 AA criteria.
['wcag2aaa']AAA-only (rarely the gate).
['best-practice']Non-WCAG good practices.
['experimental']Beta rules.

Disable specific rules

new AxeBuilder({ page }).disableRules(['color-contrast'])

For per-page disabling (e.g. a known false positive on a specific component):

new AxeBuilder({ page })
  .exclude('.legacy-component')   // selector exclusion
  .analyze();

For per-rule severity in CI gating (e.g. block on critical / serious only): handle in a11y-violation-gate using the impact field.

Related skills

a11y-violation-gate

Builds a CI gate that fails the build on **new** WCAG / a11y violations introduced by a PR while grandfathering pre-existing violations on a per-rule / per-page baseline. Aggregates verdicts from axe-core / pa11y / Lighthouse a11y / WAVE / IBM Equal Access scans. Use when a project has accumulated a11y debt and a strict "zero violations" gate would block every PR - the ratchet pattern lets the team ship while preventing regressions.

aria-authoring-patterns

Reference for the W3C ARIA Authoring Practices Guide (APG) - covers the 31 canonical interactive-widget patterns (Combobox, Dialog, Menu, Tabs, Tree, etc.), their required ARIA roles and states, the keyboard-interaction model per pattern, and the canonical-violations to watch for. Use when authoring a custom interactive widget that doesn't have a native HTML equivalent, or when reviewing one for ARIA correctness.

ibm-equal-access-a11y

Authors and runs IBM Equal Access accessibility-checker scans - IBM's open-source a11y engine with WCAG 2.0 / 2.1 / 2.2 + US Section 508 rule sets, integrating with Node / Selenium / Puppeteer / Playwright / Karma / Cypress test runners. Distinguished by IBM's enterprise-tier rule coverage and Section 508 specificity. Use when the project ships to US federal / public-sector customers (Section 508 mandate) or when the team values IBM-branded a11y reporting.

lighthouse-a11y

Configures Lighthouse CI's Accessibility category for automated accessibility testing (a11y / WCAG coverage) - `categories:accessibility` audits backed by axe-core (axe) - with per-URL minimum-score assertions (fail a build when a page's score drops below a threshold) and per-audit overrides, distinct from the Performance category that `lighthouse-perf` covers. Use when the project already runs Lighthouse CI for Web Vitals and the team wants to add accessibility coverage in the same pipeline rather than spinning up a separate scanner.

pa11y-a11y

Authors and runs pa11y accessibility scans - a CLI / Node.js tool that wraps HTML CodeSniffer (htmlcs) and / or axe-core engines - with `pa11y {url}` invocation, reporter selection (cli / csv / json / html / tsv), WCAG standard selection (WCAG2A / WCAG2AA / WCAG2AAA), and rule ignoring. Use when the project needs scriptable a11y scans without a full test framework, or when a Node-stack project wants an alternative to direct axe-core use.

screen-reader-test-author

Builds a screen-reader test narrative - a step-by-step manual test script for NVDA (Windows), JAWS (Windows), VoiceOver (macOS / iOS), or TalkBack (Android) - that exercises a specific user flow through a component or page and captures the expected announcement at each step. Use when authoring an accessibility-acceptance test the team will run before sign-off, OR when scripting a manual a11y audit.

wave-a11y

Runs WebAIM WAVE accessibility scans via the WAVE API or the browser-extension UI - produces visual overlay of errors / alerts / structural elements directly on the page, plus categorized JSON output for CI use. Use when the team values manual-review-friendly visual feedback (the WAVE overlay) alongside automated CI scans, or when a regulatory audit requires WebAIM-branded reports.

wcag-checklist-builder

Builds a per-component WCAG 2.2 accessibility checklist from a component spec - covers focus management, color contrast, ARIA roles & states, keyboard interaction, error handling, and live-region announcements - emitting a markdown checklist or YAML test plan that pairs with screen-reader-test-author for manual verification and the violation gate for automated scans. Use during component-spec review or pre-implementation acceptance.

wcag-color-contrast

Reference for WCAG 2.2 color-contrast conformance - covers SC 1.4.3 Contrast (Minimum, AA), 1.4.6 Contrast (Enhanced, AAA), 1.4.11 Non-text Contrast (AA), and 1.4.13 Content on Hover or Focus (AA) - with the canonical contrast ratios (4.5:1 normal text, 3:1 large text and UI components), measurement formula references, and bulk design-token checking patterns. Use when designing a color palette, reviewing a component for accessibility, or auditing existing CSS for contrast violations.

wcag-compliance-reporter

Builds a per-page WCAG 2.2 compliance score report by aggregating output from one or more accessibility scanners (axe-core / pa11y / lighthouse / WAVE / IBM Equal Access), pivoting violations by Success Criterion (1.4.3 contrast, 2.4.7 focus visible, etc.), grouping by conformance level (A / AA / AAA), reporting per-page coverage gaps explicitly (the "this page wasn't scanned" failure mode), and emitting both an executive summary and a per-page drill-down. Use after a multi-page accessibility scan - pa11y-ci, axe across a sitemap, lighthouse-batch - when the team needs a shareable conformance report rather than a per-page tool dump.

wcag-focus-trap

Reference for **intentional** focus management in modal / dialog / drawer / popover components - the canonical pattern that satisfies WCAG SC 2.4.3 (Focus Order) without violating SC 2.1.2 (No Keyboard Trap). Covers focus-on-open, focus-cycle-within-container, Escape-closes-and-restores, return-to-trigger, and inert-the-rest-of-the-page. Use when authoring or reviewing any component that displays content over the page (modals, drawers, popovers, command palettes).

wcag-keyboard-navigation

Reference catalog for WCAG 2.2 keyboard-navigation conformance - covers SC 2.1.1 (Keyboard), 2.1.2 (No Keyboard Trap), 2.1.4 (Character Key Shortcuts), 2.4.3 (Focus Order), 2.4.7 (Focus Visible), 2.4.11/2.4.12 (Focus Not Obscured) - with conformance levels (A/AA), test scripts, and per-criterion failure patterns. Use when authoring or reviewing keyboard-only interaction support.

widget-a11y-test-matrix

Per-widget manual accessibility test matrices where every row pairs one keystroke with the expected focus behavior, the expected NVDA announcement, the expected VoiceOver announcement, and the WCAG 2.2 success criterion that row verifies. Covers button, toggle button, checkbox, text input, modal dialog, menu button, and combobox archetypes, plus universal Tab traversal. Use when a rendered widget has cleared automated scanning and a tester needs a fill-in pass/fail sheet to run by hand against NVDA and VoiceOver.