Template · Fixing findings

Remediation plan Template

One row for each finding: how severe it is, how much work the fix is, the priority that follows, who owns it, when it is due, and whether the retest passed. It comes filled with six findings for the audit template's example shop, four of them from its register: replace them with yours.

Version
1.0
Updated
2026-10-07
Standard
WCAG 2.2
Priorities
P1-P4
Format
CSV + Markdown
Licence
CC0 1.0
The plan .csv The guide .md

Download

The files

Plain text files you can open anywhere.

CSV

The plan

remediation-plan.csv

Six example rows for the audit template's shop, one per finding. Open it in a spreadsheet, or import it into your issue tracker.

Format
Comma-separated values (RFC 4180)
Size
1,419 bytes
Contents
13 columns, 6 rows

Preview: the header and the first 3 rows

ID,Finding,WCAG criterion,Severity,Effort,Priority,Owner,Target release,Due date,Status,Retest date,Retest result,Notes
AUD-001,Card errors shown only by a red border,3.3.1 Error Identification,Critical,Medium,P1,Checkout team,v4.12,2026-10-01,Closed,2026-10-02,Pass - retested with the keyboard and a screen reader,"The error summary is now a design system component, ready for every form."
AUD-002,Password field blocks paste and password managers,3.3.8 Accessible Authentication (Minimum),High,Small,P1,Accounts team,v4.13,2026-10-08,In progress,,,Check the sign-up and password reset forms for the same paste blocker.
AUD-003,No visible focus on the sort and filter buttons,2.4.7 Focus Visible,Medium,Small,P2,Design system team,v4.14,2026-10-15,Open,,,"Fix the focus style in the shared button, so every toolbar gets it."

The columns, in order

  • ID
  • Finding
  • WCAG criterion
  • Severity
  • Effort
  • Priority
  • Owner
  • Target release
  • Due date
  • Status
  • Retest date
  • Retest result
  • Notes
Download the file

Markdown

The guide

remediation-plan.md

How to run the plan: severity, effort and priority, response times, status, the weekly review and retests. Keep it beside the plan.

Format
Markdown text (.md)
Size
6,293 bytes
Contents
114 lines

Preview: the first 16 lines

# 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
Download the file

Licence: CC0 1.0 Universal, a public domain dedication. Copy, change and use these files for anything, including paid work, without asking or giving credit. The files are plain ASCII text in English, so they open the same everywhere.

What goes in it

What goes in the plan

The findings register says what is wrong. The plan says who fixes it, by when, and whether the fix worked.

  1. The finding. Its ID, title and criterion from the findings register. The detail stays in the register.
  2. Severity. Critical, High, Medium or Low: the effect on people, copied from the register.
  3. Effort. Small, Medium or Large: how much work the fix is, estimated by the team that will make it.
  4. Priority. P1 to P4, read from the priority table, not chosen by feel.
  5. Owner and dates. One team or person, the release the fix is planned for, and the date it is due.
  6. Status. Open, In progress, Fixed - awaiting retest, Closed or Won't fix, as in the audit.
  7. Retest. When the fix was checked with the steps that found the problem, and the result. Only a pass closes a row.

Column by column

Columns of the plan

The first four come from the findings register. The rest belong to the plan.

Columns of the plan (table)
ColumnWhat to write
IDThe finding's ID in the findings register, such as AUD-001. One row per finding.
FindingIts title, copied from the register.
WCAG criterionThe number and name, such as 3.3.1 Error Identification.
SeverityCritical, High, Medium or Low, from the register.
EffortSmall, Medium or Large: the team's estimate of the work.
PriorityP1, P2, P3 or P4, from the priority table.
OwnerThe one team or person who will make the fix.
Target releaseThe release the fix is planned for. Leave it empty until the fix is scheduled.
Due dateYYYY-MM-DD, set from the response time for the priority.
StatusOpen, In progress, Fixed - awaiting retest, Closed or Won't fix.
Retest dateThe date the fix was retested, or is booked to be.
Retest resultPass, Fail or Partly fixed, with how it was checked.
NotesAnything else: why a date moved, a way round the problem, a related finding. For Won't fix, the reason and who decided.

Example

Priority from severity and effort

Severity down the side, effort across the top. Every row of the plan takes its priority from this table.

Priority from severity and effort (table)
SeveritySmall effortMedium effortLarge effort
CriticalP1P1P1
HighP1P2P2
MediumP2P3P3
LowP3P4P4

The rule: each severity starts at a priority, Critical P1, High P2, Medium P3 and 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.

How to use it

Run the plan

  1. Start from the register. Add a row for each finding that is not closed, with its ID, title, criterion and severity. Use the audit report template
  2. Estimate, then read the priority. The team that will make the fix estimates the effort; the table gives the priority.
  3. Agree the response times. The guide suggests a time for each priority, as a starting point. Agree yours, then give each row an owner, a release and a due date.
  4. Review it every week. Go through new findings, rows past their due date, and fixes ready to retest. Write down why a date moved.
  5. Retest before closing. Use the steps, browser and assistive technology that found the problem. Close the row, and the finding, only when the retest passes. Open the accessibility checklist

Know its limits

The dates are yours to agree

The response times in the guide 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. This template is not legal advice.

Only a passing retest closes a finding. Won't fix is a decision that someone with the authority records, with the reason, not a way to shorten the list.

Next

Related templates and tools

Sources

Where this comes from

Written by Auric Artisan. Not yet reviewed by an independent accessibility specialist.

Suggest a change to the template