How to Build an Accessibility Remediation Plan After Your Audit

An accessibility remediation plan turns an audit report into ordered, assigned work. It ranks every finding by how badly it blocks people, how many people it affects and how many pages it reaches; groups the fixes by who does them (design, development or content); sets the order of work; and ends with a re-test that proves the barriers are gone.

The short version of how to prioritize: fix anything that stops someone from completing a key task first, and start with shared components such as the header, navigation and form fields, because one fix there removes the barrier from every page at once. Then work down by severity, and put checks in place so new barriers don't creep back in.

This guide walks through each step, with a sample prioritization table and an example ticket you can adapt. If you haven't had an audit yet, start with what a website accessibility audit involves.

What an accessibility remediation plan includes

A useful plan is short enough to follow and specific enough to act on. It should have:

• Every finding from the audit, each with a priority, an owner and a status
• The order of work, grouped into phases or sprints
• Who is responsible for design, development and content fixes
• A date for the re-test, and who will do it
• The checks that will stop the same issues coming back
• Where progress will be recorded and published

Keep the findings in your normal issue tracker rather than a separate spreadsheet that nobody opens. Accessibility work that lives outside the backlog tends not to get done.

How to prioritize WCAG issues

Every finding gets a priority from three things: severity, user impact and reach. Effort breaks ties.

Severity: how badly does it block someone?

Most audit reports use four levels:

• Critical: someone can't complete a task at all. A keyboard user can't open the menu; a screen reader user can't submit the form.
• Serious: the task is possible but very hard, or information is lost. Buttons announced only as "button", errors that aren't announced.
• Moderate: frustrating, with a workaround. Focus that jumps around, link text like "read more".
• Minor: a small barrier or inconsistency that doesn't stop anyone.

User impact: is it on a key journey?

A critical barrier in your checkout matters more than the same barrier on an archived news page. Rank findings on the journeys that matter most to your users and your business (buying, booking, applying, signing in, contacting you) above those on low-traffic pages.

Reach: shared components first

A finding in the site header, footer, navigation, a form component or a page template is on every page that uses it. These are the highest-value fixes in any plan: one change in one place, and the barrier is gone everywhere. If you use a design system or component library, fix the component there, not page by page.

Effort: the tiebreaker

Between two findings of equal priority, do the quicker one first. Many audit findings, such as a missing label, a wrong heading level or a low-contrast colour token, take minutes. Clearing them early shows progress and builds the team's confidence.

The AODA baseline

If your organization is covered by the AODA, its legal baseline for public websites is WCAG 2.0 Level AA. When two findings are otherwise equal, the one that fails a WCAG 2.0 A or AA criterion goes first. A good audit report marks which findings fall inside that baseline. But don't use this as a reason to skip newer criteria. Issues like focus hidden behind a sticky header (2.4.11 Focus Not Obscured, added in WCAG 2.2) still block real people.

A sample prioritization table

Here is how a handful of findings from a typical audit might be ranked. Priority 1 is fixed first.

Notice the footer contrast issue. It's on every page, but it's minor, so it doesn't jump the queue. And it's a one-line colour change, so it will often get done early anyway.

Building your accessibility remediation roadmap

A practical fix order for most teams looks like this:

1. Critical barriers in shared components. Header, navigation, skip link, form controls, dialogs. One sprint here usually removes a large share of the findings.
2. Critical and serious barriers on key journeys. Work through each journey from start to finish until a keyboard user and a screen reader user can complete it.
3. Design tokens and templates. Colour contrast, focus styles, heading structure and reflow, fixed at the source.
4. Remaining serious and moderate findings, by template, in order of traffic.
5. Content fixes. Alt text, link text, headings and captions, often handled by content editors in parallel with development.
6. Minor findings, folded into normal work.

Put dates against the first two phases at least. If your organization files an AODA compliance report or keeps a multi-year accessibility plan, those dates are what you'll point to.

Assigning fixes to design, development and content

Not every accessibility issue is a developer issue, and routing findings to the right people speeds things up considerably.

• Design: colour contrast, focus indicator styles, target sizes, layouts that don't reflow, information shown only by colour, and the designs for any new accessible component.
• Development: keyboard support, accessible names and roles, form labels and error handling, focus management in dialogs and single-page apps, ARIA, page titles and language.
• Content: alt text, heading order within articles, meaningful link text, captions and transcripts, and accessible PDFs and Word documents.

Give each group a named owner. For development work, one person who understands the front-end architecture should own the shared-component fixes, so they're made once and properly.

How to write accessibility tickets that get fixed

A ticket that just says "fix WCAG 4.1.2" will sit in the backlog. Copy the audit finding into the ticket, and add a clear test for "done".

Title: Quantity buttons have no accessible name (WCAG 4.1.2, Serious)

Where: Product template, cart drawer (shared QuantityStepper component)

What happens: Screen readers announce the + and - buttons only as "button".
Users can't tell what they do or which product they change.

Fix: Give each button an accessible name, e.g.
  <button type="button" aria-label="Increase quantity of Sourdough loaf">+</button>
Announce the new quantity in a polite live region.

Done when:
- NVDA + Firefox and VoiceOver + Safari announce "Increase quantity of [product], button"
- The updated quantity is announced after each press
- Works with keyboard only (Tab to the button, Enter or Space to activate)

Writing the acceptance test in terms of what a keyboard or screen reader user experiences keeps everyone focused on the outcome, not just the code change.

How to fix accessibility issues without creating new ones

Remediation only sticks if new code and content don't reintroduce the same problems. Build these checks into how your team already works:

• Linting. Accessibility lint rules catch some problems as code is written, such as eslint-plugin-jsx-a11y for React or the template accessibility rules in angular-eslint for Angular.
• Automated checks in CI. Run axe-core against your key pages and journeys on every pull request, and fail the build on new violations.
• Accessible components. Fix issues in your design system or component library, document the accessible usage, and make teams use the shared component rather than building their own.
• A definition of done. New features are keyboard-tested and screen-reader spot-checked before release.
• Content training. Editors who know how to write alt text and structure headings stop a large share of content issues at the source.

Here's a minimal automated check using Playwright and axe-core:

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('checkout has no detectable WCAG A/AA violations', async ({ page }) => {
  await page.goto('/checkout');
  const results = await new AxeBuilder({ page })
    .withTags(['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'])
    .analyze();
  expect(results.violations).toEqual([]);
});

Automated checks like this are a safety net, not a substitute for testing. As Playwright's own documentation notes, automated testing cannot detect all types of WCAG violations. Our guide to automated vs. manual accessibility testing explains where the line falls.

Retesting: proving the fixes work

When a phase is done, re-test each finding the same way it was found: with the same keyboard steps, the same screen reader and browser combination, at the same zoom level. Checking only the code isn't enough; a correct-looking ARIA attribute can still be announced wrongly.

An independent re-test by the original auditor gives you an updated report showing what's fixed and what's still open. That is the evidence you'll want for leadership, buyers and any compliance filing. Book it when you start remediation, not when you finish, so there's a fixed date to work towards.

Documenting progress

Record what you've done, where the people who need it will find it:

• Accessibility statement. Update your public statement with the standard you're working to, known issues still open, and how people can get help or give feedback. See how to write an accessibility statement.
• ACR (VPAT). If you've given buyers an Accessibility Conformance Report, update it after the re-test so it matches the product as it is now. Our ACR and VPAT reports are written from audit findings and updated after fixes.
• AODA multi-year accessibility plan. Ontario organizations with 50 or more employees, and designated public sector organizations, must have a multi-year accessibility plan, review it at least once every five years and post it on their website. Your remediation roadmap is natural content for it. See Ontario's guidance on accessibility plans.

Frequently asked questions