Web accessibility remediation plan template
A remediation plan turns audit results into owners, deadlines, and proof of re-testing. Below is the full structure: severity levels, the tracking table, deadline defaults, the order to work in, and how to report progress. Copy it into your own tracker.
What a remediation plan is for
An audit produces a list of failures. A remediation plan turns that list into decisions: who fixes what, by when, and how you will know it is fixed. It is also the document a customer, auditor, or opposing counsel will ask for when they want to know whether you are working on the problem or only know about it.
A plan only works if it starts from a real audit. The W3C's evaluation method, WCAG-EM, describes the steps that come before it: define the scope, explore the site, choose a representative sample of pages, evaluate that sample, and report the findings. Our WCAG 2.2 checklist gives you the criteria to evaluate against.
Step 1: Severity levels
Triage every issue on one scale. The four levels below are a working convention, not a standard: neither WCAG nor any law defines them, so write your definitions into the plan.
| Severity | Definition | Example |
|---|---|---|
| Critical | A user cannot complete a core task at all, with any assistive technology. | The checkout button is a div with a click handler and cannot be reached or activated by keyboard (2.1.1). |
| High | A workaround exists, but it is hard or unreliable. | Primary buttons have 2.8:1 contrast; AA needs 4.5:1 for normal text (1.4.3). |
| Medium | The task is doable and the workaround is reasonable, but the experience is degraded. | Headings jump from h1 to h4 (1.3.1). |
| Low | Minor or cosmetic, with little effect on completing a task. | Redundant alt text next to a visible caption (1.1.1). |
Step 2: The tracking table
One row per issue. Copy these columns into a spreadsheet, Jira, Linear, or Notion:
| ID | Issue | WCAG 2.2 | Severity | Where | Owner | Due | Status | How verified |
|---|---|---|---|---|---|---|---|---|
| A-001 | Light gray body text on white | 1.4.3 | High | Design system tokens | Design lead | 30 days | In progress | Contrast checker plus scanner re-run |
| A-002 | Product images have no alt text | 1.1.1 | High | Product template | Dev team | 30 days | Not started | Scanner re-run plus screen reader pass |
| A-003 | Promo video has no captions | 1.2.2 | Medium | Landing page | Marketing | 90 days | Not started | Play with captions on |
| A-004 | Form fields not announced by label | 3.3.2 | Critical | Signup form | Dev team | 2 weeks | Fixed | Awaiting screen reader re-test |
The example issues come from the barrier types the US Department of Justice lists in its web guidance: poor color contrast, missing alt text, no captions on videos, inaccessible forms, and mouse-only navigation (ADA.gov web guidance). Always cite the specific success criterion; it is the first thing a reviewer asks for.
Use five statuses, and keep "Fixed" and "Verified" apart
- Not started and In progress: self-explanatory.
- Fixed: the change shipped.
- Verified: someone other than the fixer re-tested and confirmed the barrier is gone. State the method: automated re-scan, keyboard pass, or screen reader pass with the assistive technology and browser named.
- Won't fix: always with a reason you could defend, such as third-party content outside your control or content scheduled for removal. "We didn't get to it" is Not started.
Step 3: Deadlines and order of work
Deadlines are your own commitments, not legal requirements. A sensible starting set: Critical, 2 weeks; High, 30 days; Medium, 90 days; Low, next redesign cycle. If a contract, a customer, or a regulator gives you an earlier date, that date wins. Clear Critical and High items well before it.
When everything looks urgent, sequence the work like this:
- Critical issues on money paths first: checkout, signup, login, the main call to action.
- Shared components next. One fix in a shared header or button component clears the issue on every page that uses it.
- Cheap, high-impact fixes before expensive ones. A missing alt attribute is a five-minute fix. Rebuilding a custom widget's keyboard handling should be scheduled, not squeezed in.
Step 4: Report on a schedule
- Weekly: one line in the engineering standup, for example "Accessibility: 2 Critical and 5 High open, 3 closed this week."
- Monthly: a short written note covering items closed, items open by severity, anything at risk of missing its date, and any new Won't fix entries with reasons.
Keep one source of truth. A plan that lives in two spreadsheets is a plan nobody updates. Your accessibility statement can describe known issues and the fix timeline you are committed to. Re-run the free accessibility scanner after each release.
A plan is a record of good-faith work. It does not prevent a demand letter or lawsuit; if you receive one, see our guide to the ADA demand letter response and get counsel involved.
Start from a filled-out structure, not a blank page
Core Kit ($99) includes the remediation plan template with severity definitions, tracking table, deadline defaults, prioritization rules and reporting cadence, plus the WCAG 2.2 self-audit checklist that feeds it.
Get Core — $99 Run the free accessibility scannerFAQ
What should a web accessibility remediation plan include?
A scope and the audit it is based on, severity definitions, one row per issue with the WCAG success criterion, owner, deadline, status and verification method, rules for prioritization, and a reporting cadence.
How long do I have to fix accessibility issues?
Your plan sets them. Choose deadlines by severity, and follow any earlier date in a contract, customer requirement, settlement or regulator notice.
What is the difference between Fixed and Verified?
Fixed means the change shipped. Verified means someone re-tested it and confirmed the barrier is gone, using a stated method such as a keyboard or screen reader pass.
Is this legal advice?
No. This page is general information and professional documentation guidance, not legal advice, and reading it does not create an attorney-client relationship. Have qualified counsel review anything you publish or send to a regulator, buyer, or court, especially if you have received a legal notice.