From Audit to Compliant: Building an Accessibility Remediation Roadmap That Finishes
Most accessibility programmes die at the report. The difference between an audit and compliance is a sequenced, owned roadmap that fixes components rather than pages.
An accessibility audit lands as a spreadsheet: 380 findings across nineteen templates, each mapped to a success criterion, each with a severity. It is technically accurate and organisationally inert. Six months later, forty items are closed, sixty new ones exist, and the accessibility initiative is quietly described as ongoing.
The failure is not effort. It is that the audit was structured for reporting rather than for execution. This is how to restructure it.
Step 1 — Convert page findings into component defects
This single reframing typically reduces a 380-item register to fewer than sixty real defects. An inaccessible modal reported on twelve templates is one defect. An unlabelled search field in the header is one defect appearing on every page. Group findings by the component that produces them, and the work becomes finite.
| Reported as | Actually is | Fix location |
|---|---|---|
| 47 contrast failures | Three token values below threshold | Design tokens |
| 31 unlabelled inputs | One form field component | Component library |
| 19 focus-trap failures | One modal implementation | Component library |
| 26 heading-order issues | Two page templates and an editorial guideline | Templates plus CMS guidance |
| 12 keyboard-inoperable menus | One navigation component | Component library |
Step 2 — Sequence by impact, not by criterion number
Order the work in four tiers and resist the temptation to reorder for convenience.
- Blockers. Anything that makes a revenue or account journey impossible to complete with keyboard or screen reader. These are both the highest user harm and the highest legal exposure.
- Serious barriers. Journeys completable but with significant difficulty — poor error handling, missing landmarks, unclear focus.
- Systemic quality. Contrast tokens, heading discipline, alternative text conventions, motion preferences.
- Long tail. Historical content, archived documents, low-traffic templates.
Tier one is usually a few weeks of work and removes most of the exposure. That is the argument that gets the programme funded.
Step 3 — Fix at the source, in the right order
Remediate design tokens first, then shared components, then templates, then page-specific code, then content. Working in that sequence means each layer's fixes propagate downward; working in reverse means fixing the same defect repeatedly and reintroducing it on the next build. Alongside this, editorial content needs its own track: alternative text, link text, heading structure and document accessibility are authoring behaviours, not engineering ones, and they need guidance plus CMS-level validation rather than tickets.
Step 4 — Close the regression gate before you finish
A programme that reaches conformance without prevention has bought a temporary state. Four gates hold it:
- Automated accessibility tests on the component library, failing the build rather than filing a warning.
- Keyboard operability and screen reader sanity checks in the definition of done for any interactive work.
- Accessibility annotation in design handoff — focus order, landmark structure, alternative text intent — so ambiguity is resolved before code exists.
- Contractual conformance requirements for third-party widgets, with a named owner reviewing each vendor's report annually.
Step 5 — Keep the evidence trail
Both regulators and enterprise buyers respond to evidence of a managed programme far more favourably than to claims of perfection. Maintain test records per journey and assistive technology combination, a dated defect register showing resolution over time, a version history of your published accessibility statement, and vendor conformance reports. This is also what makes writing an Accessibility Conformance Report a matter of assembly rather than of guesswork.
A realistic timeline for a mid-size estate
Weeks 1–3: audit with automated and manual testing, converted immediately into a component-level register with tiers.
Weeks 4–8: tier-one blockers cleared on revenue and account journeys; tokens and the three most-used components fixed.
Weeks 9–16: remaining shared components and templates; editorial guidance issued and CMS validation added.
Weeks 17–24: long tail, regression gates in CI, vendor clauses, statement published, ACR assembled from retained evidence.
The organisations that finish are not the ones with the largest budgets. They are the ones that stopped treating 380 findings as 380 problems.
Turning a report into completed work
The value of an audit is entirely determined by what happens in the eight weeks after it lands. We scope remediation as an engineering programme with owners, sequences and regression gates — because that is the only version that ends.
Kinematic Digital runs WCAG 2.2 AA audits combining automated scanning with manual keyboard and screen reader testing, then fixes the defects at design-system level so one correction propagates across every template. See our UX and accessibility services and web development practice, or request an accessibility audit.
Frequently Asked Questions
How long does accessibility remediation take?
For a mid-size site, expect a first pass on critical journeys within four to eight weeks and full WCAG 2.2 AA conformance across templates in three to six months. The variable is not the audit but how many bespoke components exist without an accessible pattern behind them.
Should we fix everything at once?
No. Sequence by user impact and legal exposure: blockers on revenue and account journeys first, then serious barriers, then the long tail. A programme that tries to clear 400 findings simultaneously stalls.
Who should own accessibility remediation?
The design system or platform team, with legal and procurement enforcing gates. If ownership sits only with QA, accessibility becomes a release-blocking argument rather than a build-time default.
How do we stop new accessibility issues appearing?
Automated checks on the component library in CI, keyboard operability in the definition of done, accessibility annotations in design handoff, and conformance clauses in third-party contracts.
What evidence should we keep?
Test records per journey and technology, a dated defect register with resolution status, your published accessibility statement history, and vendor conformance reports. Evidence of a managed programme is what regulators and buyers respond to.