Send the plan and the measured result together, and never let the plan stand in for the result. Your roadmap is a statement about what you intend to do. Your conformance report is a statement about what your product does today. A customer who receives the second one quietly replaced by the first has been told something untrue, and the moment somebody on their side opens the product, they will know it.
None of which is an argument against writing one. The largest buyer in the world asks suppliers for a remediation plan by name, and the position it gives that plan is the whole answer to what a roadmap is for. Federal acquisition guidance sorts what an agency asks of a supplier into two tiers. The conformance report and its supporting document are required. Remediation plans and accessibility improvement plans are recommended, sitting beside the report rather than in place of it.
So the roadmap is supporting evidence about your intentions, filed next to evidence about your product. Read that way it is a strong document, because a dated list of real gaps with owners against them is a thing very few suppliers can produce. Read the other way, as a substitute for testing, it is the fastest way to lose a buyer's trust in everything else you sent.
Four things a roadmap does not do
It does not make the product conformant. It does not repair anything. It does not change a row in a report you have already issued, because that row records a measurement rather than an intention. And it says nothing at all about pages nobody tested, because a plan can only order findings somebody went and gathered.
Three Columns Turn a Wish List Into a Plan
Most roadmaps that get rejected fail on the same three fields, and all three are missing for the same reason, which is that filling them in requires agreement from people outside the document. That is not a flaw in the format. It is the format doing its job, because a plan nobody has agreed to is a wish list with a header on it.
- An owner. A named person or a named team, not a department and not the word engineering. An item with no owner is the item we come back and find untouched, every time.
- A dependency. What has to be true before this can start. Half the items on a real roadmap are waiting on something else, and a plan that hides that is a plan whose order makes no sense to the people who have to work it.
- A retest gate. What proves the item is done, and who checks. Not a date, and not the word fixed. A gate is a condition somebody other than the author can evaluate, which is the only kind of done that survives a handover.
A Worked Roadmap, With Gates Instead of Dates
This is an illustration rather than a template to copy, because the sequence depends on findings you have and we do not. What it shows is the shape. Six items, each one with a person against it, a stated dependency and a gate that somebody else can check. No completion dates appear anywhere in it, and the next section explains why that is deliberate rather than evasive.
| Item | Owner and dependency | Retest gate |
|---|---|---|
| Keyboard trap in the date picker, blocking booking at step two | Owner: the component library maintainer. Depends on nothing, which is why it is first. | The full booking process completes with the keyboard alone, on two browser and screen reader pairings, verified by somebody who did not write the fix. |
| Form fields with a visible label that is not wired to the input | Owner: the front-end lead. Depends on the shared form component landing first, because the fix is one change in one file. | Every field in the tested set reports its own label to the accessibility tree, checked by inspection rather than by the developer's own screen-reader pass. |
| Contrast failures across the marketing pages | Owner: the design system owner. Depends on the palette decision, which is a business decision rather than an engineering one. | Every text and background pairing in the token set meets the ratio, and the tokens are the only source the pages draw from. |
| Errors announced visually and never to assistive technology | Owner: the checkout squad. Depends on the shared form component, so it queues behind the label work. | A submitted form with three errors announces all three, and the same message appears in text on the page. |
| Video captions missing across the help center | Owner: the content team, with a named editor. Depends on a captioning supplier being appointed, which nobody has done yet. | Every video in the tested set carries captions somebody watched, with the supplier's quality check recorded against each file. |
| Native mobile applications, entirely untested | Owner: unassigned. Depends on somebody being given it, which is the first thing to fix here. | No gate can be written until a scope for the testing exists. Until then this item stays on the plan as a known unknown rather than dropping off it. |
The last row is the one to copy. An item you cannot yet plan stays on the plan, described as unplanned, because a buyer reading a roadmap is trying to work out what you know about your own product. Deleting the row that says nobody owns the mobile apps does not make the mobile apps any better and it does make your document less honest.
Why Gates Beat Dates on a Document a Customer Keeps
A date is a promise. A gate is a condition. That difference is small inside your own sprint planning and large the moment the document leaves the building, because a customer files what you sent them and reads it again at renewal. A date you missed is a broken written commitment sitting in their records with your name on it. A gate that has not been reached yet is a status, and it reports itself accurately for as long as it takes.
There is a second reason, and it is the one that decides the argument. Nobody can honestly date work whose size is not yet known, and accessibility work is full of items whose size is not known until somebody opens the code. Writing a confident date over an unknown produces exactly the failure this whole subject turns on, which is a supplier asserting something they cannot support. If your delivery team has agreed a date and will stand behind it, put it in. If they have not, a gate says more and risks less.
What a buyer can reasonably ask for instead of dates is order, and order is a thing you can honestly supply. Which item is first, what it is waiting on, and what will prove it done.
Sequence by Process, Not by Criterion
Grouping the plan by success criterion is the instinct, and it produces a plan that never finishes anything. The standard is the reason. Where a page is one step of a process, every page in that process has to conform for any of them to conform, so a checkout with a barrier at step four is not a checkout that is most of the way there. It is a checkout that does not conform.
Sequence by journey instead and each block of work ends with something a customer can be told. The booking process now completes with a keyboard. The account signup now works with a screen reader. Those are sentences you can put in an email. "We closed thirty 1.3.1 findings" is not, because it leaves every journey exactly as unfinished as it was.
One more thing follows from the same requirement and catches people out. A full page includes each variation the page presents automatically at different screen sizes, and each variation has to conform. So a fix verified at desktop width has been verified at one width, and the narrow layout is a separate check rather than a formality.
The Roadmap Does Not Rewrite Your Report
This is where suppliers get themselves into trouble, usually with good intentions. A criterion that measured as Partially Supports keeps that verdict until somebody retests it and it measures as something else. You do not write the planned state into the row, and you do not soften the remark because the fix is scheduled. The report is dated for exactly this reason, and a buyer comparing your report against your roadmap is checking whether the two documents agree about the present.
The template gives you nowhere to record a pending state anyway. Below Level AAA there is no permitted way to write that something is in progress, so any attempt to express it lands in one of the four verdicts and asserts a finding. Put the intention in the roadmap, where intentions belong, and let the report keep saying what was true on the day it was signed.
What to Send With the Plan
- The dated report the findings came from. A roadmap with no evidence behind it is a list of assertions, and the buyer has no way to tell whether the gaps you named are the gaps you have.
- The scope statement. What was tested, how many pages, and what was left out. This is the field that tells a reader how much of your product the plan speaks for, and the report itself has nowhere to put it.
- A named owner for the plan as a whole. Separate from the item owners, and reachable. Somebody has to answer when the customer asks in six months how it went.
- A review cadence. When the plan gets looked at again, and what triggers an unscheduled review, which is usually a release that changes the interface.
One honest limit
We write the plan and we check the work, and we never do the fixing. One firm writing the plan, working the plan and then grading the plan is three hats with no independent step anywhere in the chain, so we only ever wear the first and the third. The remediation roadmap is the deliverable, priced per document on top of the audit it sequences, and it inherits that audit's scope. No plan is a promise that any customer will accept it, and nobody can honestly sell you that promise.