# Accessibility remediation plan: [name of the site or product]

> Template version 1.0, 2026-10-07, from https://auricartisan.com/templates/remediation-plan/
> Licence: CC0 1.0 (https://creativecommons.org/publicdomain/zero/1.0/). Copy it, change it and use it for anything; no credit needed.
> Replace everything in [square brackets], then delete this note. The plan itself is remediation-plan.csv: one row per finding.

| Plan | |
|---|---|
| Site or product | [Name and address] |
| From the audit | [Name of the audit report or a link to it, and its date] |
| Plan owner | [Name, role] |
| Weekly review | [Day, time and who attends] |
| Response times agreed by | [Names, YYYY-MM-DD] |
| Last reviewed | [YYYY-MM-DD] |

## 1. How the plan links to the findings register

The audit's findings register (accessibility-findings.csv in the audit template) says what is wrong. This plan says who fixes it, by when, and whether the fix worked.

- Add one row to the plan for each finding that is not closed, with the same ID, such as AUD-001.
- Copy the finding's title, WCAG criterion and severity. Keep the description, steps to reproduce and recommendation in the register; do not copy them here.
- Keep Status, Retest date and Retest result the same in both files: when you change one, change the other.

## 2. Severity

Severity measures the effect on people, not the level of the criterion: a Level AA failure can be critical and a Level A failure can be low. The plan uses the register's scale; copy the severity, do not judge it again.

| Severity | Meaning |
|---|---|
| Critical | Blocks a task: some people cannot complete it on their own, or are put at risk. |
| High | The task can be done only with serious difficulty or a workaround most people will not find, or important information is missing for some people. |
| Medium | The task takes clearly more time or effort, or is confusing, but people get through it. |
| Low | A minor annoyance or inconsistency with little effect on getting things done. |

## 3. Effort

The team that will make the fix estimates the effort before the work starts. [Change the meanings to fit how your team estimates.]

| Effort | Meaning |
|---|---|
| Small | One change in one place: a person can make and test it in a day or two. |
| Medium | Several places, a shared component, or design work first: up to about two weeks. |
| Large | A redesign, a third-party component to replace, or many pages of content: more than two weeks. |

## 4. Priority

Priority comes from severity and effort, by this table. Do not set it by feel: if a priority looks wrong, check the severity and the effort.

| Severity | Small effort | Medium effort | Large effort |
|---|---|---|---|
| Critical | P1 | P1 | P1 |
| High | P1 | P2 | P2 |
| Medium | P2 | P3 | P3 |
| Low | P3 | P4 | P4 |

The rule: each severity starts at a priority (Critical P1, High P2, Medium P3, Low P4), and a Small fix moves up one step, because it costs little to do now. Medium and Large effort leave it where it is, so effort never lowers a priority.

## 5. Response times

These are suggestions, counted from the day a finding is added to the plan. They are a starting point for your team to agree, not a standard: WCAG says what to meet, not how fast to fix what does not. A law, a contract or a complaint may set its own deadline; where one does, it comes first.

| Priority | Suggested response |
|---|---|
| P1 | Start now and fix within 2 weeks. If the problem is not live yet, hold the release. |
| P2 | Fix within 30 days. |
| P3 | Fix within 90 days. |
| P4 | Fix when the area is next changed, and within 6 months. |

Set each row's Due date from its priority, and its Target release to a release that ships by that date. Leave Target release empty until the fix is scheduled.

## 6. Status

| Status | When to use it |
|---|---|
| Open | The fix is planned but not started. |
| In progress | Someone is working on the fix. |
| Fixed - awaiting retest | The fix is live, or on a test site, and waits for its retest. |
| Closed | The retest passed. |
| Won't fix | Someone with the authority decided not to fix it. Write the reason, who decided and when in Notes, and how people can get round the problem. |

## 7. The weekly review

Once a week, [the plan owner] goes through the plan with the owners:

1. Add new findings from the register, with their severity, effort and priority.
2. Look at every row past its due date: agree a new date, and write in Notes why it moved.
3. Book a retest for every row that is Fixed - awaiting retest.
4. Close the rows whose retest passed. Set the rows whose retest failed back to In progress.
5. Count the rows that are not closed, by priority, and share the count with [who needs it].

## 8. Retest before closing

- Retest each fix with the steps, browsers and assistive technology that found the problem, and check that nothing near it broke.
- Write the date in Retest date and the result in Retest result: Pass, Fail or Partly fixed, with how it was checked.
- Close a row only when its retest passes. If it fails or is partly fixed, set it back to In progress and keep the same ID.
- Where you can, have someone other than the person who made the fix do the retest.

## 9. The columns of remediation-plan.csv

| Column | What to write |
|---|---|
| ID | The finding's ID in the findings register, such as AUD-001. One row per finding. |
| Finding | Its title, copied from the register. |
| WCAG criterion | The number and name, such as 3.3.1 Error Identification. |
| Severity | Critical, High, Medium or Low, from the register. |
| Effort | Small, Medium or Large: the team's estimate of the work. |
| Priority | P1, P2, P3 or P4, from the table in section 4. |
| Owner | The one team or person who will make the fix. |
| Target release | The release the fix is planned for, or empty until it is scheduled. |
| Due date | YYYY-MM-DD, from the response time for the priority. |
| Status | Open, In progress, Fixed - awaiting retest, Closed or Won't fix. |
| Retest date | The date the fix was retested, or is booked to be. |
| Retest result | Pass, Fail or Partly fixed, with how it was checked. |
| Notes | Anything else: why a date moved, a way round the problem, a related finding. For Won't fix, the reason and who decided. |