A Remediation Roadmap Puts the Fix List in Working Order

What We Keep Finding

An audit ranks findings by user impact, which tells you what hurts most. It does not tell you what to do Monday. Impact alone would send your team into a navigation rebuild while the alt text a junior developer could clear by lunch sits untouched for a quarter. A working plan weighs both sides. How much a barrier hurts, and what removing it costs.

So we sequence the findings into sprints. Quick wins up front, template-level fixes grouped so one change clears many pages, structural work placed where your actual velocity can carry it. The grouping is where most of the money is on a templated site, and it is the part a findings list hides from you. A theme can override what your e-commerce plugin sets. A contributed module never passes through the platform's own accessibility review. So the same broken component renders on every page that calls it, and forty findings turn out to be one fix in one file.

There is a shortcut worth talking you out of first. "We will just fix the serious and critical ones" sounds like a narrow start and is not one. Of the 70 rules carrying a WCAG A or AA tag, 63 run once the experimental and deprecated ones drop out, and 58 of those 63 can report a serious or critical result. So that filter keeps nearly the whole list and tells you almost nothing about what to do first. Severity was never an ordering. Two scores are. What the barrier costs a user, and what the fix costs you.

What the roadmap is not is the repair. We write the plan, your team or your supplier does the work, and we come back and check it, which is the arrangement that keeps the checking worth anything. There is no version of this where we quote you for the doing instead, because we do not sell it at any price. One firm writing the plan, working the plan and then grading the plan is three hats and no independent step anywhere in the chain, so we only ever wear the first and the third.