Turn your existing test results into an accessibility statement

If you already run axe-core, pa11y or Lighthouse, most of the evidence for a statement exists. The gap is turning findings into a document that cites the right clauses and says only what the evidence supports.

The pipeline

Evidence in, document out, with every conclusion traceable back to what produced it:

axe.json, pa11y.json, lighthouse.json, manual.yaml
        ↓
  parsed into findings, per rule and per URL
        ↓
  mapped: tool rule → WCAG criterion → EN 301 549 clause
        ↓
  conformance per criterion, with the evidence attached
        ↓
  statement · ACR · burden worksheet · traceability report

How a tool finding becomes a conformance claim

Each rule maps to the success criteria it actually evidences. axe's color-contrast maps to WCAG 1.4.3, and therefore to EN 301 549 clause 9.1.4.3. Rules that map to no criterion — best-practice rules such as region — are kept and reported separately rather than being silently dropped or attributed to a criterion they do not evidence.

Where sources disagree, the precedence is fixed and documented: a manual assessment outranks a tool, a failure outranks a pass, and anything unevaluated stays unevaluated. Conflicts are surfaced rather than resolved quietly — if you record a manual pass over an automated failure, the traceability report says so, because whoever signs the statement should see it.

What automated results cannot do

This is the part worth being blunt about, because it is where generated statements go wrong. A scanner can tell you an image has no alt attribute. It cannot tell you whether the alt text you wrote is meaningful, whether the reading order survives CSS being disabled, whether your error messages suggest a correction, or whether a video's captions are accurate.

Those criteria are not optional parts of the standard. Leaving them unevaluated is a legitimate and honest position; recording them as passing because nothing was flagged is not. The generated manual checklist enumerates them with guidance so the gap is visible rather than implicit.

Keeping it true

A statement is accurate on the day it is generated. The check command exists so it stays that way: it compares the current conformance position against a committed baseline and fails the build when a criterion regresses.

npx accessibility-statement check

Losing coverage counts as a regression too — a criterion moving from evaluated to unevaluated is treated the same as a failure, because the statement's claim weakens either way.

Try it

The browser generator takes a JSON report and produces the document immediately. Nothing is uploaded; the whole engine runs in the page. For the manual checklist, version control and the CI gate, use the command-line tool.

Related

• What the European Accessibility Act requires in a statement
• EN 301 549 and WCAG
• VPAT, ACR and OpenACR

Common questions

Can I generate an accessibility statement from axe-core results?

Partly, and the boundary matters. Automated tools reliably detect a subset of accessibility problems — commonly estimated at around a third — so axe results can evidence specific failures but cannot establish conformance for criteria no tool can judge, such as whether alt text is meaningful or whether focus order preserves meaning. A statement generated from a scanner alone should report those criteria as not evaluated rather than as passing.

What formats can be used as evidence?

This tool reads axe-core JSON (a single result or an array of per-page results), pa11y JSON and pa11y-ci JSON, and Lighthouse JSON reports. Multiple files merge into one project view with per-URL provenance kept, so a rule that fails on the checkout page and passes on the help page is recorded as exactly that.

What is the manual checklist for?

It covers the criteria automation cannot judge — media alternatives, meaningful sequence, focus order, error suggestion, consistent identification and the rest. The tool generates a template listing every WCAG A and AA criterion that automated testing cannot fully assess, with guidance on how to check each one, and manual entries take precedence over tool output.

Can this run in CI?

Yes, and that is the intended use. The check command compares current conformance against a committed baseline and exits non-zero when a criterion regresses, so a statement stays true after the day it was generated rather than becoming a stale snapshot.