How do I get an HTML report out of Pa11y CI?

Install `pa11y-ci-reporter-html` and add it to the `reporters` array in `.pa11yci` — it writes `pa11y-ci-report/index.html` with a page per URL scanned. That folder is what you publish.

How do I share it with designers who don't run Node?

Publish the folder to Comma and send the URL. Nobody needs npm, a local server, or a copy of the repo — and the person who has to fix the contrast ratio can comment directly on the issue.

Does the per-page drill-down still work?

Yes. `index.html` becomes the report body and the per-page files upload alongside it with their relative links rewritten, so clicking into a specific URL's issues works the way it does locally.

Should I publish a passing run?

Publish every run to the same report id. The useful artifact is the trend — an accessibility regression is only obvious next to the revision before it.

Can we track which issues we've accepted?

Yes, and that is the real reason to publish. Anchored threads sit on the issue, so 'this is a false positive on the icon button, it has an aria-label the scanner misses' is attached to it rather than relitigated every sprint.

Share a Pa11y CI accessibility report

Accessibility work fails on distribution more than on will. The scanner runs in CI, prints "12 errors across 5 URLs", and the three people who could fix them — a designer, a front-end engineer, and whoever owns the component library — never see the actual issues.

Pa11y CI has an HTML reporter for exactly this gap:

npm i -D pa11y-ci pa11y-ci-reporter-html

{
  "defaults": { "standard": "WCAG2AA" },
  "reporters": ["cli", ["pa11y-ci-reporter-html", { "destination": "./pa11y-ci-report" }]],
  "urls": ["https://example.com/", "https://example.com/pricing"]
}

npx pa11y-ci      # → pa11y-ci-report/index.html + a page per URL

Which is, again, a folder — and a folder is why it stays on the runner.

Publish the folder

Drag pa11y-ci-report/ (or a zip of it) into the app:

index.html becomes the report body.
The per-URL pages and styles upload alongside it with their relative links rewritten to the uploaded copies, so the drill-down works.
Scripts run inside a sandboxed iframe, so any interactive filtering behaves.

From CI, PATCH the same report id on every run so the URL is stable and each run appends a revision — see publishing from CI.

Why the comment layer matters for a11y specifically

Accessibility issues are triaged, not just fixed. Some are false positives. Some are real but owned by a vendor component. Some are one line of CSS. That triage is the expensive part, and it gets redone from scratch every quarter because nobody wrote it down next to the issue.

Anchored threads on the issue — "false positive, the icon button has an aria-label the scanner does not read". See commenting on HTML.
Revisions — one report id per site, one revision per run, so a regression has a visible before.
Access per report — private, team, domain-gated, or named reviewers. See the sharing model.

On a schedule

Point a routine at the scan so the report refreshes on a cron and the people subscribed get told when it changes — an accessibility report that is only true on the day it was generated is not much of a report.

Limits

Entry HTML: 5 MB. Assets: 25 MB per file, 250 MB and 500 files total — a scan across hundreds of URLs writes a page each, so watch the file count and split by section.
60 requests/minute per token.

Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision history.

Publish an accessibility report →