Axe plugin

[matejchalk]

Metric

100+ web accessibility metrics provided by Axe (listed here).

User story

EAA compliance is likely to be a growing concern in the coming years for companies based in Europe. From June 25, 2025, all new digital products and services in the EU market must meet accessibility standards defined by the EAA. For services that were already in operation before that date, the law allows a transition period until June 30, 2030. The requirements are closely aligned with the Web Content Accessibility Guidelines (WCAG).

This is expected to increase demand for accessibility testing tools. Therefore, building an A11Y solution into Code PushUp would make it more appealing for many potential customers.

Accessibility is somewhat covered by existing plugins:

• Lighthouse measures an Accessibility category with ~50 pass/fail audits (uses axe-core)
• ESLint can be configured to check source code for A11Y anti-patterns using plugins like eslint-plugin-jsx-a11y or @angular-eslint/eslint-plugin-template

However, neither seems to be as comprehensive as Axe.

Dependencies

• axe-core
• @axe-core/cli (optional)
• @axe-core/puppeteer (optional)
• @axe-core/playwright (optional)

Acceptance criteria

• plugin executes axe-core with user-provided configuration
  • multiple URLs can be provided
  • custom scripts may be provided, which serve to programmatically reach certain application states
• plugin parse JSON report from AXE and convert results to Code PushUp data models
  • Axe rules should map to (binary) audits 1-to-1
  • violations should be reported as issues with a given severity level
  • at least one accessibility group should be provided, to simplify configuration
• plugin E2E tests run against local example app
• plugin is (manually) tested against some application which requires a login (e.g., Code PushUp Portal)

Implementation details

The simplest way to run Axe is via its CLI. E.g.:

npx @axe-core/cli https://mdn.github.io/learning-area/accessibility/html/bad-form.html --save=axe.json

However, we need to consider that for many modern applications, it won't be sufficient to provide a URL, as many features won't be reachable without a user login or some other interaction. Therefore, we should provide users with the option to provide their own test scripts to reach the application states they're interested in. These scripts could be written using one of the testing tools Axe supports (e.g., Playwright, Puppeteer, WebdriverIO).