Accessibility Roadmap: 24-Week Plan to Reach WCAG 2.2 AA

8 min read ยท 2026-10-25

An accessibility roadmap is a time-bound plan that takes your product from its current state to a target standard, usually WCAG 2.2 level AA, and keeps it there. It lists which flows you will fix first, who owns each fix, how you will test, and when you will publish proof such as an accessibility statement or a conformance report.

The roadmap below covers 24 weeks in six phases. It starts with a baseline audit and ends with accessibility built into how your team designs, codes and ships. Each phase ends with a milestone you can check. You also get a filled-in example for a SaaS product, a triage method, the roles involved and the metrics to report. Laws differ by country and sector, so confirm your legal obligations with counsel. This guide covers the planning.

The roadmap at a glance

Goal: Your core user flows meet WCAG 2.2 AA, new work is tested before release, and you publish an accessibility statement and conformance report you can stand behind. Duration: 24 weeks

  1. Scope and baseline audit (Weeks 1-3)

    Agree on the target standard and measure where the product stands today.

    • Pick the target, usually WCAG 2.2 level AA, and confirm it with legal and product leadership.
    • List the five to ten flows that matter most: sign-up, log-in, checkout or billing, core task, settings, help.
    • Run automated scans on those flows with a tool such as axe DevTools, Lighthouse or WAVE.
    • Have an accessibility specialist test the same flows by hand with a keyboard and a screen reader such as NVDA or VoiceOver.

    Milestone: An audit report listing every issue by flow, WCAG success criterion and severity, signed off by the product and engineering leads.

  2. Triage and plan (Weeks 4-5)

    Turn the audit into a ranked backlog with owners and dates.

    • Log each issue as a ticket in Jira or Azure DevOps with an accessibility label, the criterion and the flow.
    • Rank issues by severity and by how many users hit the flow.
    • Group issues that share a root cause, such as one broken modal component used on 40 screens.
    • Assign each group to a squad and agree on target sprints with the engineering manager.

    Milestone: A ranked accessibility backlog where every blocker has an owner and a target sprint.

  3. Fix blockers in core flows (Weeks 6-11)

    Remove the issues that stop people from finishing key tasks.

    • Fix keyboard traps, missing focus states and controls that cannot be reached without a mouse.
    • Add names and labels to form fields, buttons and icons so screen readers announce them.
    • Fix error messages so they are announced and say how to correct the input.
    • Retest every fix with a keyboard and a screen reader before closing the ticket.

    Milestone: No open blocker in the core flows, confirmed by a retest from the specialist.

  4. Fix the design system (Weeks 8-15)

    Fix shared components once so every screen that uses them improves.

    • Check color tokens against WCAG contrast ratios and update the ones that fail.
    • Rebuild shared components such as modals, menus, tabs and date pickers following WAI-ARIA authoring practices.
    • Add accessibility notes to each component in your docs and in the Figma library.
    • Release the fixes as a versioned update and track which product teams have upgraded.

    Milestone: Updated components released, with contrast, keyboard and screen reader checks passed for each one.

  5. Build testing into delivery (Weeks 12-18)

    Stop new issues from reaching production.

    • Add an automated accessibility check, such as axe-core, to your CI pipeline on key pages.
    • Add accessibility items to the definition of done and to the pull request template.
    • Add an accessibility review to design critique for new flows.
    • Train designers, developers and QA on keyboard and screen reader testing in short hands-on sessions.

    Milestone: Automated checks run on every pull request for key pages, and the definition of done includes accessibility.

  6. Validate, publish and govern (Weeks 19-24)

    Prove where you stand and keep it that way.

    • Run a second audit on the core flows with the same method as the baseline.
    • Recruit people with disabilities for usability sessions on the main task.
    • Publish an accessibility statement with known issues, a contact channel and fix dates.
    • Prepare a conformance report, such as a VPAT-based ACR, if customers or public buyers ask for one.
    • Set a review rhythm: monthly backlog review and a full audit each year or after major redesigns.

    Milestone: Second audit shows the core flows meet the target, with the statement published and an owner named for ongoing compliance.

Example: an accessibility roadmap for a B2B SaaS product

Picture a project management app with a web client used by a few thousand companies. A public sector prospect asks for a conformance report, and the audit finds 140 issues across six flows. Most come from four shared components. Here is how the six phases could play out.

Notice the overlap between phases. Design system fixes start while blockers are still being fixed, because the biggest gains come from fixing shared components early. The roadmap also commits to a date for the conformance report, which is what sales needs to keep the deal moving.

  • Weeks 1-3, owner product manager: WCAG 2.2 AA confirmed, six flows audited. Milestone: 140 issues logged, 18 blockers.
  • Weeks 4-5, owner engineering manager: issues grouped into 30 root causes. Milestone: every blocker assigned to one of three squads.
  • Weeks 6-11, owners squad tech leads: sign-up, log-in and task creation fixed. Milestone: zero blockers in those flows on retest.
  • Weeks 8-15, owner design system lead: modal, dropdown, date picker and toast rebuilt, two color tokens changed. Milestone: version 3.2 adopted by all three squads.
  • Weeks 12-18, owner QA lead: axe-core runs in CI on 25 key pages. Milestone: no pull request merges with a new serious violation on those pages.
  • Weeks 19-24, owner product manager: second audit, statement live, ACR sent to the prospect. Milestone: core flows meet the target.

How to triage accessibility issues

An audit of a mature product can return hundreds of issues. If you fix them in the order the report lists them, you spend weeks on minor pages while users still cannot complete checkout. Rank each issue on two axes: how badly it blocks someone, and how many people pass through that flow.

Then look for shared causes. One date picker used across 30 screens counts as one fix with 30 results. Ticket the component, not the 30 screens.

  • Blocker: a user cannot finish the task, such as a keyboard trap in a modal or an unlabeled pay button.
  • Serious: the task is possible but very hard, such as missing error messages or poor focus order.
  • Moderate: it causes confusion or extra effort, such as unclear link text or low contrast on secondary text.
  • Minor: a small issue with an easy workaround, such as a decorative image announced by screen readers.

Who owns what

Accessibility fails when it belongs to everyone and no one. Give one person overall accountability, usually a product manager or an accessibility lead, and make each role responsible for its own part of the work.

If you have no in-house specialist, bring in an outside auditor for the baseline and the second audit. Use the time in between to build skills in your own team.

  • Product manager or accessibility lead: owns the roadmap, the backlog ranking and reporting to leadership.
  • Designers: contrast, focus states, layout at zoom, clear labels and error text in every new design.
  • Developers: semantic HTML, keyboard support, ARIA where needed, and fixing tickets.
  • QA: keyboard and screen reader checks in test plans, plus the automated checks in CI.
  • Design system lead: accessible shared components and tokens.
  • Legal or compliance: the target standard, the accessibility statement and conformance report review.

Metrics to track

Report a few numbers every month, always against the baseline audit. Leadership wants to see the trend, not a raw list of tickets.

Pair the numbers with one short story from usability sessions, such as a screen reader user who could not finish sign-up at baseline and now can. It makes the work real for people who never use assistive technology.

  • Open blockers and serious issues in core flows: counted from the backlog, by flow.
  • Core flows that meet the target: confirmed by manual retest, not only by scans.
  • New issues per release: from CI checks and QA, to show whether prevention works.
  • Time to fix: average days from report to fix for blockers and serious issues.
  • Design system coverage: share of shared components that passed accessibility review.

How to present it to leadership

Lead with the reason the business cares. That can be legal exposure, a deal that needs a conformance report, a public sector buyer, or users who cannot complete a task today. Then show the six phases on one slide with dates, owners and the milestone for each.

Leave out the full issue list and the success criteria numbers. Show instead the open blocker count by flow, the capacity you need from each squad, and the date for the second audit. Ask for one clear decision, such as a fixed share of each sprint for the next six months.

How to adapt it

A small startup can shrink the plan to eight to twelve weeks: audit only the sign-up and core task, fix blockers, add an automated check and write the statement. A large company with many products should run the roadmap per product line, with a central team owning the target, the design system and training.

Mobile apps need their own audit. Test with VoiceOver on iOS and TalkBack on Android, check dynamic type and touch target size, and fix shared native components first. If your product handles documents, add PDF and email templates to the scope, since they are often forgotten until a customer complains.

Common mistakes to avoid

  • Relying only on automated scans misses many real problems, so pair every scan with manual keyboard and screen reader testing.
  • Fixing issues screen by screen wastes effort, so fix shared components and tokens first.
  • Treating accessibility as a one-time project lets issues creep back, so add checks to CI and to the definition of done.
  • Publishing a claim of full conformance without proof creates risk, so publish known issues and dates in your statement instead.
  • Leaving accessibility to one specialist creates a bottleneck, so train designers, developers and QA to check their own work.
  • Testing only with internal staff hides real barriers, so include people with disabilities in usability sessions.

Frequently asked questions

What should an accessibility roadmap include?

It should include the target standard, a baseline audit, a ranked backlog with owners, fixes to shared components, testing built into delivery, and a plan to publish and maintain an accessibility statement. Each phase needs a milestone and an owner.

Which WCAG level should we target?

Most organizations target WCAG 2.2 level AA, since it is the level most laws and buyers refer to. Some contracts or regulations still name WCAG 2.1 AA. Confirm the exact requirement with your legal team or the buyer.

How long does it take to make a product accessible?

It depends on the size of the product, the number of issues and how much comes from shared components. Many teams can fix the core flows within one or two quarters if they fix the design system early. Keeping the product accessible is ongoing work.

What is a VPAT?

A VPAT is a template that vendors fill in to describe how well a product meets accessibility standards. The completed document is called an Accessibility Conformance Report, or ACR. Public sector and enterprise buyers often ask for one during procurement.

Can automated tools make a site accessible?

No. Automated tools find some issues quickly, such as missing alt text or low contrast, but cannot judge things like logical focus order or clear labels. Use them in CI and pair them with manual testing.

Generate this roadmap with AI