What a credible accessibility roadmap looks like to buyers
A government buyer reads your accessibility roadmap alongside your VPAT. What it needs: criteria, versions, dates, progress reporting, and no vague promises.
Almost every Accessibility Conformance Report a government buyer receives has gaps. Buyers know this. What separates a report they can award on from one they cannot is usually not the number of "Partially Supports" rows but what comes with them: an accessibility roadmap that says what will be fixed, in which release, and by when. This article is about writing one that a procurement officer will believe.
Why buyers ask for an accessibility roadmap
State and local governments are working toward fixed dates. Under the ADA Title II web rule, public entities with a total population of 50,000 or more must meet WCAG 2.1 Level AA by 26 April 2027, and smaller entities and special district governments by 26 April 2028. The rule covers web content and mobile apps they provide "directly or through contractual, licensing, or other arrangements", which includes your product.
So when a buyer reads your ACR, the question is not only "does this conform today?" but "will it conform by our date, and how will we know?" Your roadmap answers the second question. It may also end up in the procurement file, and sometimes as an exhibit to the contract, which means it should be written as something you are prepared to be held to.
What a credible roadmap contains
A roadmap a buyer can use has one entry per gap, and each entry is checkable.
Criterion numbers, matching your ACR. "1.4.3 Contrast (Minimum)", not "color improvements". The buyer will lay your roadmap beside your conformance table and match them row by row. Every criterion you report as "Partially Supports" or "Does Not Support" should either appear on the roadmap or be explained as a deliberate decision.
The affected feature. Where in the product the gap is, in terms a buyer recognizes: "the payment confirmation page", "the agenda PDF export", "the mobile app sign-in screen".
The fix. One sentence describing the change, not the aspiration.
The target release and a date. A version identifier and at least a quarter. A date without a release cannot be verified against an updated ACR; a release without a date cannot be planned around.
Status. Planned, in development, in testing, shipped. Updated when it changes.
Interim workarounds, where they exist. ITI's VPAT instructions already suggest that remarks include known workarounds; the roadmap is a natural place to repeat them for open items.
Vague versus usable
The same commitment, written two ways:
We are committed to accessibility and are continuously improving our product toward full WCAG 2.1 AA compliance. Remaining items will be addressed in upcoming releases.
| Criterion | Feature | Fix | Release | Target | Status |
|---|---|---|---|---|---|
| 2.1.1 Keyboard (A) | Date picker, permit application | Replace with keyboard-operable date input | 8.4 | Q1 2027 | In development |
| 1.4.3 Contrast (Minimum) (AA) | Secondary buttons, all pages | Darken button text to meet 4.5:1 | 8.4 | Q1 2027 | In testing |
| 4.1.2 Name, Role, Value (A) | Custom tab component, dashboard | Add tab roles and selected state | 8.5 | Q2 2027 | Planned |
The first is a statement of intent. The second is a plan, and it is the one a buyer can put in a file, track and defend.
How to prioritize, from the buyer's side
Buyers do not weigh all gaps equally, and a roadmap that reflects how they weigh them reads as more credible.
- Level A first. Level A criteria are the floor of WCAG conformance. A roadmap that schedules AA polish ahead of a Level A keyboard failure looks like it was ordered by engineering convenience.
- Public workflows next. Anything a resident must use to pay, apply, register or read official information matters more than administrative screens.
- Before the customer's date, with margin. A fix shipping the week before 26 April 2027 leaves the customer no time to verify it, deploy it, or deal with a slip. Aim to land fixes for core workflows well before the dates your customers face.
If a customer has asked for WCAG 2.2, the nine criteria added in 2.2 belong on the roadmap too. The Title II rule itself requires WCAG 2.1 Level AA, so be clear about which standard each entry addresses.
How the roadmap pairs with the ACR
The two documents do different jobs and should not blur into each other.
The ACR describes the version that exists. It should report what the product does now. Do not mark a criterion "Supports" because the fix is scheduled; that is the single fastest way to lose a reviewer's trust, because the claim will be tested.
The roadmap describes what will change. It should reference the ACR by product version and date, so a reader knows which report it is the plan for.
When a release ships, both move. Publish an updated ACR for the new version. ITI's instructions say a revised report should carry a new date and explain the revision in its Notes section, or state that it supersedes the earlier report. Close the corresponding roadmap entries in the same update, so the two documents agree. More on cadence in how often a VPAT should be updated.
The remarks in your ACR can also point to the roadmap: "Partially Supports. The date picker on the permit application cannot be operated by keyboard; typed entry is available as a workaround. Fix scheduled for release 8.4 (Q1 2027)." That one remark does more for a reviewer than a page of general commitments. See VPAT remarks examples for more.
Reporting progress
A roadmap that is never updated becomes a liability on the date the first item slips. A few habits help:
- Update on a fixed cadence, quarterly at least, and with each release.
- Keep stable identifiers. The same entry should be recognizable from one update to the next, so a buyer can see movement.
- Report slips before the buyer finds them, with the new date and a reason. A slip disclosed early, with a credible new date, is routine. One discovered by the customer reads as concealment.
- Never quietly drop an entry. If an item is closed because it was fixed, say which release. If it was descoped, say why.
What to leave out
- "Fully compliant" language. A roadmap is an admission that the product is not there yet. Claims of full compliance elsewhere in your materials will be read against it.
- An overlay as the fix. Entries that say "addressed by accessibility widget" will be read as unfixed. See accessibility overlays and procurement.
- Dates you would not sign. If the roadmap may become a contract exhibit, every date in it is a potential commitment. Conservative and kept beats ambitious and missed.
The short version
A credible accessibility roadmap is specific, dated, tied to criterion numbers and product versions, consistent with your ACR, and updated. It is not a marketing document, and buyers can tell the difference within a page. For the report it accompanies, see how to fill out a VPAT.
Sources: 28 CFR part 35, subpart H (the DOJ's 2024 Title II web rule) and the DOJ's interim final rule of 20 April 2026 on compliance dates; ITI VPAT 2.5Rev template instructions; W3C WCAG 2.1 and 2.2. This is general guidance, not legal advice.
GOVvpat can review your conformance report before you submit it, the way a government reviewer will read it. See how it works for vendors.