Mitigation and Remediation

A Remediation & Mitigation Plan supplements your Voluntary Product Accessibility Template (VPAT). While the VPAT records the current conformance status of the product against WCAG 2.1(2) and Section 508, this plan explains how you can close the gaps that remain. It lists every known accessibility defect, rates each one by the impact it has on real users, assigns ownership, and commits to a concrete fix-by date. It also documents any interim accommodations you provide so that users with disabilities can achieve equivalent access while a permanent fix is in progress. Procuring agencies, legal reviewers, and internal stakeholders can use this plan to verify that accessibility debt is being tracked, resourced, and resolved on a schedule that meets our service-level obligations.

Table of Contents


Note:

Note: During my accessibility discussions with agencies and partners it has paid off to be prepared with the mitigation fix window information then allow for negotiation if their opinions don't align with yours. Most of the time they have been happy with the time lines.

Purpose

When you attach a mitigation & remediation plan to a VPAT (Voluntary Product Accessibility Template), reviewers look for three things:

  1. What's wrong
  2. How bad it is (user impact)
  3. What we'll do and when

The next 3 sections show tables examples of a Severity Scale, Accessibility Issue Tracker example and a Remediation Timeline example.

Table 1, The Severity Scale tabele might show the Severity, What that severity means (definition), typical WCAG failures based on that definition, a possible time and a typical interim accommodation.

Table 2, The Issue Tracker table might show a Summary, the severity that has been set, status and dates to completion of the various issues. I've found it helps to also show where the issue is and assign it an ID of sorts.

Table 3, Defines how long an issue might take to fix, suggests timelines and deliverables in those timelines.

1. Accessibility Severity Scale (User-Impact Driven)
Severity Definition (user impact) Typical WCAG failures Timelines Typical Interim Accommodation
Critical / Blocker User cannot complete a core task with assistive tech.
  • No keyboard focus on sign-in
  • Form can't be submitted with screen-reader
 ≤ 30 calendar days (hot-fix or emergency release). Rarely feasible—must ship fix.
High Major difficulty or confusion; task possible but with workarounds.
  • Incorrect heading order on checkout
  • Custom widget lacks ARIA
 ≤ 60 calendar days (included in next scheduled release). Alternate workflow (phone / accessible PDF) documented.
Moderate Causes friction; practical workaround exists.
  • Low-contrast text in secondary content
  • Missing alt on non-essential images
 ≤ 120 calendar days (quarterly release). Documented workaround or guidance provided.
Low / Cosmetic Annoyance that does not block understanding.
  • Redundant ARIA roles
  • Minor reading-order quirks
 When touched (no later than 1 year or the next major UI refresh). None required.

2. Accessibility Issue Tracker - Sample Rows
ID Page/View Issue Summary Severity Status Fix Target Date
ACC-001 /login Screen reader does not announce login error message High Open 2025-06-10
ACC-002 /dashboard Chart colors lack sufficient contrast Moderate In Progress 2025-08-01
ACC-003 /profile/settings Keyboard focus is not visible on save button Critical Open 2025-05-30
ACC-004 /search Search field lacks associated label High Fixed 2025-05-12
ACC-005 /terms PDF download link lacks accessible description Low Deferred 2026-01-01

Guidelines

  • IDs never change once issued.
  • Include exact screen/node so QA can retest quickly.
  • Link each row to its Jira ticket (e.g., ABC-123).

3. Accessibility Remediation Timeline and Gates
Stage Time Window Deliverables / Actions
Triage 0-15 days - Severity confirmed
- Owner Assigned
- Jira ticket created
Design & Development 15-60 days Fix implemented behind feature flag
QA / AT Validation 60-75 days Manual SR + keyboard tests, automated regression
Release ≤ 90 days Fix live, VPAT updated

4. Interim accommodations

Describe how an affected user can obtain equivalent access until the permanent fix is live (alternate HTML page, accessible PDF, phone line, etc.).

5. Review Cadence

This plan is reviewed quarterly. Resolved items move to the main VPAT; new findings are added within 30 days of discovery.

6. Plain-Language Principle

Avoid developer jargon; write so procurement, legal, and auditors can follow without technical context.

Best-Practice Checklist

  • Severity reflects user impact
  • Each row maps to WCAG success criterion + unique ID
  • Owner & target date committed
  • Interim workaround documented for Moderate or higher
  • Review cycle stated
  • Document stored alongside code backlog for traceability

UAT/Release Testing or Other

If an agency finds a defect during UAT, Phased Release Testing or some other random occurrence, we need to be prepared. Give the agency a structured spreadsheet (or form) to log any defects they discover. It shows we're prepared to ingest findings quickly and fold them into the same workflow we use for internally discovered issues.

A few tips to make that hand-off run smoothly:

  1. Match your internal fields
    Use the same columns you have in your Confluence tracker—ID, WCAG SC, description, severity, steps to reproduce, screen / component, date found, reporter, and optional screenshots. When you import the file, there's no re-mapping or data loss.
  2. Provide guidance on severity
    Like in this document, see above.
  3. Acknowledge receipt
    When the agency returns the sheet, reply with a quick “All issues loaded as tickets XYZ-123-XYZ-130; you'll see them reflected on the Confluence page within 24 hours.” That closes the loop and builds trust.
  4. Update the VPAT & plan
    Once each external issue is triaged, update the severity/timeline table in Confluence so the VPAT addendum stays the single source of truth.

Timelines for accessibility issues and their response

Spell out clear response expectations up-front. Without them, defects can linger in email threads and throw off your own remediation schedule.

Typical Time-boxes for Accessibility Issue Handling
Phase Who acts Recommended window Rationale
Discovery → Submission Agency testers ≤ 2 business days after the defect is observed Gives testers time to capture reproduction steps and screenshots but keeps feedback fresh.
Submission → Acknowledgment Your team 1 business day Confirms receipt, assigns internal ticket number, and communicates severity.
Acknowledgment → Triage> Accessibility lead / product owner 3 business days Validates the issue, sets severity, and enters the fix window listed in your plan.

Tips for making it stick

  1. Include the timeline in the SOW or test plan. Write it as an acceptance criterion so everyone signs off.
  2. Be flexible for blockers. If testers find a Critical issue that stops UAT, allow same-day escalation outside the normal window.
  3. Review after each cycle. If the business/agency/customer consistently meets (or misses) the timeline, adjust the window or resources next sprint.
Back to top