Remediation Timelines That Survive Contact With Reality

2026-10-15

Every accessibility program eventually produces the meeting where someone asks how long remediation will take, and someone else answers with a date built by dividing the audit's issue count by an optimistic daily rate. That date is fiction. Issue counts measure how your templates repeat, not how much work your team has to do.

Real timelines come from a different unit of analysis entirely: the root cause. Until findings are grouped that way, nobody in the room, not leadership, not the vendor, not the development team, actually knows whether remediation is a sprint or a program.

Group findings by root cause before estimating anything

A typical audit returns hundreds of findings that collapse, on inspection, into a few dozen root causes: a header template missing skip logic, a design system button with insufficient contrast, a third party widget injecting unlabeled fields. Estimating against the collapsed list produces timelines that are shorter, more accurate, and far less frightening to present.

The grouping work is analysis, not clerical labor. It requires someone who can read a finding and recognize the component behind it across forty pages, which is why it belongs with senior developers and the auditor together. Handed to a spreadsheet alone, the same findings stay four hundred line items and the timeline stays fiction.

Sequence templates and design system fixes first

Order matters more than speed. A template level fix closes findings on every page that template touches, the moment it ships, while page by page remediation burns weeks re-solving the same defect in forty places. Programs that start with shared components routinely close the majority of findings in the first third of the timeline.

There is a second, quieter benefit: sequencing templates first shrinks the surface that content teams can re-break. Every week spent fixing individual pages while the underlying templates still generate defects is a week of new findings being published. Fix the source, then sweep the instances, then set up the regression checks that keep the source fixed.

Estimate with ranges and name the unknowns

Honest timelines are ranges with named risks: the checkout widget is vendor controlled and its fix date is a negotiation, the video library's captioning depends on a transcription budget not yet approved, the legacy template's owner left in March. A single date pretends none of that exists, and the pretense is discovered on the worst possible schedule, near the end.

Estimate in the units the work actually uses. Developer days for code fixes, production time for captions and document remediation, review cycles for legal and brand sign off on alternative text for key journeys. Summed honestly with their dependencies, these produce a timeline leadership can staff against, instead of a number everyone privately disbelieves.

Report burn down by cause, severity, and journey

Progress reporting decides whether a long remediation keeps its support. Pages touched is a vanity metric that can rise while user impact does not move. Report root causes closed, weighted by severity, and status per critical journey: can a screen reader user now complete checkout, contact support, apply for an account. Those are the units stakeholders and, frankly, regulators think in.

Publish the remaining unknowns with the same prominence as the wins. A remediation report that surfaces the blocked vendor fix in month one gives leadership time to apply commercial pressure. The same blocker revealed in month five reads as an excuse. In accessibility programs, bad news early is a management tool, not a failure.

Frequently asked questions

Why are timelines based on issue counts always wrong?

Because issue counts measure repetition, not work. One template defect can generate hundreds of findings and take a day to fix at the source, while a single finding in a vendor component can take a month of negotiation. Grouping findings by root cause is what turns an audit into an estimable backlog.

What should be fixed first in remediation?

Shared templates and design system components, because one fix closes findings across every page using them and stops new pages from inheriting the defect. Page level fixes come after, as a sweep of instances, followed by regression checks that keep the templates from reintroducing the problems.

How should remediation progress be reported?

By root causes closed, weighted by severity, and by the status of critical user journeys, such as checkout or account creation for assistive technology users. Pages touched rises even when user impact does not, so it misleads leadership about how much risk has actually been retired.

How do we handle vendor components in the timeline?

Name them as external dependencies with their own track: the fix requested, the vendor's committed date if any, and the interim mitigation you control, such as replacing, wrapping, or removing the component. Vendor items hidden inside a general timeline become the surprises that destroy its credibility.