Auditing, remediation and compliance reporting
Choosing automated scanners, structuring a manual audit, prioritising fixes by user impact, VPAT and EN 301 549 evidence, and building accessibility into CI.
Structuring an audit
| Method | Finds | Misses | Cost |
|---|---|---|---|
| Automated scanner | Missing labels, contrast, duplicate ids, missing alt | Whether the alt text is useful, whether the flow makes sense | Minutes |
| Structured manual pass | Keyboard traps, focus order, semantics, headings | Issues specific to a real assistive technology | A day per template |
| Screen reader testing | Announcements, live regions, form behaviour | Anything only visible in a magnifier or a switch setup | A day per flow |
| Assistive technology users | The barriers people actually hit | Nothing important, if recruited well | Depends on the study |
| Accessibility conformance report | Whether a specific standard is met | Nothing about usability | Weeks |
- Define the scope: which templates and which user journeys, at which conformance level, against which standard version.
- Run the scanner across the sample and record every issue with the page and the rule.
- Do a keyboard-only pass of each journey. Record every point where the user gets stuck or loses their place.
- Do a screen reader pass of the critical journeys with one or two real screen readers.
- Check zoom at 200 and 400 percent, and reduced motion.
- Consolidate into one list, then prioritise by user impact rather than by ease of fixing.
- Re-test after remediation with the same script, so the improvement is measurable.
# a scanner in CI, scoped to the pages that matter
npx pa11y-ci --config .pa11yci.json
# a single page, with a full report
npx pa11y https://example.com/checkout --reporter json > checkout-a11y.json
# and one run in the browser against the rendered DOM
# axe DevTools or the axe-core CLI, which sees client-rendered markupPrioritising fixes
| Priority | Kind of issue | Why first |
|---|---|---|
| Blocker | A task that cannot be completed at all | No workaround exists |
| Critical | A task that can be completed only with great difficulty | Excludes most users of the affected input |
| Serious | A task that is confusing or error-prone | Causes mistakes and support tickets |
| Moderate | An inconsistency or an inconvenience | Annoying but recoverable |
| Minor | A technical non-conformance with no practical effect | Fix when touching the component |
| Cosmetic | A style preference | Rarely worth the change |
- Prioritise by user impact, not by how many times an issue appears in the report. One unlabelled payment field outranks two hundred missing alt attributes on a page nobody visits.
- Fix the shared component, not the instances. Every fix at the component level removes the issue from every screen at once.
- Record what you deliberately deferred and why. An undocumented deferral is indistinguishable from an oversight.
- Retest the specific barrier with the person who reported it wherever possible.
Conformance reporting and CI
| Artefact | Answers | Audience |
|---|---|---|
| Accessibility statement | What we meet, what we do not, how to report a problem | Public, and often legally required |
| VPAT or ACR | Conformance per criterion for a named standard | Procurement and enterprise buyers |
| EN 301 549 report | Conformance for European public sector requirements | Public sector tenders |
| Audit report | Method, scope, findings, evidence | Internal and regulatory |
| Remediation plan | What will be fixed, by when, by whom | Internal accountability |
| Test evidence | Screenshots, transcripts, tool output | Supporting the above |
- State the standard and the level precisely, and the date of the assessment. Vague claims are worse than none.
- List the known non-conformances honestly, with an alternative where one exists.
- Name a contact route for accessibility problems and commit to a response time.
- Publish the statement in an accessible page and link it from the footer of every page.
- Review it at least annually and after any major release.
- In CI, fail the build on new violations rather than on the absolute count. A legacy backlog should not block every pull request.
# a pragmatic CI gate: only new violations fail the build
- name: Accessibility scan
run: npx pa11y-ci --config .pa11yci.json
- name: Fail on new violations
run: node tools/a11y-diff.js --baseline .a11y-baseline.json --fail-on new💡
A conformance report is evidence, not a goal. A site can be fully conformant on paper and still be unusable with a screen reader if the semantics are technically present and practically useless. Test with people, and let the report describe what you found rather than what you hoped.
FAQ
How many pages should an audit cover?
Every distinct template at least once, plus every critical user journey end to end. Ten well-chosen pages usually represent a site better than a random sample of a hundred.
Does fixing everything in the report mean we are compliant?
Not necessarily. Automated tools cover roughly a third of the criteria. The manual and assistive technology passes are what support a conformance claim.
Related
WCAG in plain language Accessibility in design systems and SPA frameworks
Last refreshed 2026-09-18.