An accessibility roadmap turns the findings of an accessibility audit into a plan your team can actually deliver. It answers four questions: what is broken, what gets fixed first, who owns each fix, and by when.
Rather than treating every issue as equally urgent, a roadmap groups fixes into phases, usually starting with the highest-severity barriers that fully block a task for disabled users, followed by broader remediation, and finally process changes like design system updates and staff training that prevent new issues from being introduced.
A realistic roadmap also accounts for an organization’s actual development capacity and release cycle, since an ambitious plan that ignores resourcing tends to stall, while a roadmap built around real sprints and ownership is far more likely to actually get executed.
What Goes Into an Accessibility Roadmap?
A useful roadmap is more than a list of bugs. Most good roadmaps share these seven parts:
| Roadmap component | What it covers | Why it matters |
|---|---|---|
| Baseline | Audit findings against a named standard, usually WCAG 2.2 Level AA, with the pages, templates and user journeys that were tested | Without a measured starting point, nobody can show progress |
| Scope and target | Which websites, apps, documents and third-party tools are in scope, and the conformance level you are aiming for | Sets a clear finish line and stops scope creep |
| Prioritized backlog | Every issue ranked by severity, user impact, traffic and legal risk | Blockers in checkout, login and forms get fixed before cosmetic issues |
| Phases and dates | Fixes grouped into realistic phases tied to your release cycle | Gives leadership, customers and regulators a credible timeline |
| Owners and budget | A named owner for each workstream and budget for fixes, re-testing and tools | Work with no owner and no budget is the most common reason roadmaps stall |
| Prevention | Design system fixes, accessibility checks in QA and CI, role-based training and procurement requirements | Stops new barriers from replacing the ones you just fixed |
| Verification and reporting | Re-tests, monitoring, an accessibility statement and a way for users to report problems | Proves the plan is working and catches regressions early |
W3C’s Planning and Managing Web Accessibility guide follows the same pattern: initiate, plan, implement and sustain, with clear roles and management backing so the work actually gets time and resources.
How To Build an Accessibility Roadmap in 7 Steps
- Audit your current state. Test key templates and user journeys against WCAG 2.2 Level AA, by hand and with automated tools. W3C’s WCAG-EM 2, published on 23 July 2026, gives a standard method for choosing a sample and reporting results for websites and apps. Automated scans miss many barriers, so include keyboard testing and screen reader testing with NVDA, JAWS and VoiceOver.
- Set scope and target. Decide which sites, apps and documents are in scope and which standard you will meet. WCAG 2.2 Level AA is the usual target, and W3C states that content that conforms to WCAG 2.2 also conforms to WCAG 2.0 and 2.1, so it covers policies that still name the older versions.
- Rank every issue. Score each finding by severity (does it block a task, make it hard, or just annoy), how many pages and users it affects, and where it sits. Checkout, login, forms and contact pages come first. Fix shared components early: one repaired header or form component can clear the same issue across hundreds of pages.
- Group fixes into phases. Blockers and quick wins first, then templates and components, then content, documents and media, then the long tail. Size each phase to your real sprint capacity, not an ideal one. W3C’s approaches for interim repairs help when something must be fixed urgently while the full plan runs.
- Assign owners and budget. Name an owner for design, development, content, documents and QA, and agree the budget for remediation, re-testing and tools before work starts.
- Build prevention into your process. Add accessibility checks to design reviews, code review and CI, give each role accessibility training, and write accessibility requirements into vendor contracts so new barriers do not arrive with the next plugin or third-party widget.
- Re-test, report and update. Re-test fixed issues, set up accessibility monitoring to catch regressions, update your accessibility statement, and review the roadmap at least every quarter.
Example Accessibility Roadmap: A 12-Month Plan
Here is a typical accessibility roadmap for a mid-sized website or web app. Use it as a starting template and adjust the timing to your own findings and team size.
| Phase | Timing | Typical work |
|---|---|---|
| Phase 1: Audit and triage | Weeks 1 to 4 | Audit of key templates and journeys, a backlog ranked by severity, interim fixes for blockers, and an accessibility statement with a contact route |
| Phase 2: Critical journeys | Months 2 to 3 | Fix blockers in checkout, login, search, forms and navigation: keyboard access, focus order, form labels and error messages, then re-test |
| Phase 3: Templates and components | Months 3 to 6 | Fix shared components and the design system (color contrast, headings, buttons, modals, menus), caption key videos and repair priority PDFs |
| Phase 4: Long tail and content | Months 6 to 9 | Remaining Level AA issues, older content, third-party tools and content author training |
| Phase 5: Sustain | Months 9 to 12, then ongoing | Automated checks in CI, monitoring, spot audits, accessibility in procurement, an updated statement and an annual roadmap review |
Timing depends on the size of the site and the team. A small brochure site can often finish the first three phases in a few weeks, while a large ecommerce store or SaaS platform may need the full year or longer.
Accessibility Roadmap vs Audit, Remediation Plan and Accessibility Statement
- Accessibility audit: the test that finds and documents issues. It is the main input to the roadmap.
- Remediation plan: the list of fixes for specific issues. A roadmap includes it and adds prevention, training, owners and reporting.
- Gap analysis: compares where you are with where you need to be, including processes, not only code.
- Accessibility statement: the public page that explains how accessible your site is, lists known issues and tells users how to report problems. W3C’s statement guidance advises listing known limitations and the measures you take to ensure accessibility, and both usually come straight from the roadmap.
- Accessibility maturity model: measures how well accessibility is built into the whole organization over time, while a roadmap plans the specific work to get there.
Do Laws Require an Accessibility Roadmap?
Most laws require an accessible result, not a document called a roadmap. Several do require a written plan, dated deadlines or progress reporting:
- United States (ADA Title II): state and local government web content and mobile apps must meet WCAG 2.1 Level AA by April 26, 2027 for entities serving 50,000 or more people, and April 26, 2028 for smaller entities and special district governments, under the Interim Final Rule published on April 20, 2026. A dated roadmap is the practical way to meet those deadlines.
- United States (private businesses): ADA Title III sets no technical standard for websites, but many businesses keep a documented audit and remediation roadmap so they can show what is fixed and what is scheduled if a demand letter arrives. See our guide to ADA lawsuit remediation.
- Canada (Accessible Canada Act): federally regulated entities must publish an accessibility plan, consult people with disabilities while preparing it, publish an updated plan no later than the third anniversary of the last one, and publish progress reports.
- Ontario (AODA): businesses and non-profits with 50 or more employees and designated public sector organizations must keep a written multi-year accessibility plan, update it at least once every five years and post it on their website. Designated public sector organizations must also publish an annual status report.
- United Kingdom: GOV.UK tells public sector bodies to check how far their website or app meets WCAG 2.2 and make a plan to fix the problems found, and to explain in their accessibility statement anything they cannot fix yet.
- France: organizations covered by Article 47 of Law No. 2005-102 must publish a multi-year accessibility plan (schéma pluriannuel) lasting up to three years, with the work scheduled in annual action plans.
This is general information, not legal advice. For country-specific help, see our Canada and UK accessibility compliance audits.
Get an Accessibility Roadmap Built From a Real Audit
HalfAccessible’s IAAP-certified team has 10+ years of accessibility experience. Every audit plan includes manual specialist testing, findings mapped to WCAG 2.2 success criteria and a remediation walkthrough call, so your team leaves with priorities it can act on in the next sprint.
- $500 Quick Audit: up to 5 page templates with a top-10 issues report. The fastest way to set your first-phase priorities.
- $2,000 Complete Audit: up to 25 templates or key user flows, full manual testing with JAWS, NVDA and VoiceOver, a re-test of fixed issues and an accessibility statement draft.
- $2,000 Shopify Accessibility Audit for Shopify and Shopify Plus stores.
- $100 1-hour consultation to review an existing audit or roadmap with a specialist.
Need hands-on help after the plan? Our remediation team can fix what we find, and accessibility monitoring keeps the roadmap on track. Not sure which option fits? Start with a free needs assessment or compare all pricing plans.