How to Write an Accessibility Maintenance Plan
A compliance maintenance plan is a written document that describes how an organization keeps its website conformant with WCAG over time. It assigns responsibility, sets a recurring evaluation schedule, defines how new content and code are reviewed before publishing, and records how issues are tracked from identification through remediation. A working plan is short, specific, and operational, not aspirational.
| Component | What It Defines |
|---|---|
| Ownership | Who is accountable for accessibility decisions and who performs the work. |
| Evaluation cadence | How often scans run and how often a manual expert audit is conducted. |
| Pre-publish review | How new pages, templates, and content are evaluated before release. |
| Issue tracking | Where issues live, how they are prioritized, and how remediation is recorded. |
| Training | What roles receive accessibility training and at what frequency. |
Start with Scope and Standard
The first section of the plan states what the document covers. List the websites, subdomains, web applications, and customer-facing portals included. Identify any properties that are explicitly out of scope and explain why.
State the conformance target. For most organizations this is WCAG 2.1 AA. Organizations subject to ADA Title II reference WCAG 2.1 AA directly. Some procurement contracts call for WCAG 2.2 AA. Pick one standard and write it into the plan.
Assign Roles and Ownership
A plan without named owners is a wish list. Identify the person accountable for the program, often a compliance lead, accessibility coordinator, or digital director. Below that role, list the contributors: developers who write code, designers who produce templates, content authors who publish pages, and the QA reviewers who check work before release.
Name the external partners as well. If an accessibility provider conducts the annual audit or issues an ACR, record who they are, what they deliver, and how often.
Set the Evaluation Schedule
The plan defines two distinct activities on different cadences. Automated scans run on a recurring schedule (daily, weekly, or monthly) across high-traffic and high-risk pages. Scans flag approximately 25 percent of issues, so the plan must also specify a manual expert audit cadence to cover the remaining 75 percent.
A common pattern is monthly scans paired with an annual manual expert audit, plus a fresh audit after any major redesign, platform migration, or significant feature release. Document the conditions so a new product launch does not slip past the review process.
Define the Pre-Publish Review Process
Most accessibility regression happens at the point of publishing. New pages, new templates, new images, new PDFs, and new third-party embeds are the most frequent sources of issues. The plan describes the checkpoint that catches them.
Useful items to include in the pre-publish workflow:
- Template review: any new template is evaluated for keyboard operability, heading structure, and screen reader output before it goes into production.
- Content checks: authors confirm alternative text, descriptive link text, and proper heading order before publishing.
- Document remediation: PDFs and downloadable documents are remediated before being uploaded.
- Third-party review: embedded widgets, forms, and video players are evaluated before being added to a page.
- Code review: pull requests touching front-end code include an accessibility check as part of the review.
Document Issue Tracking and Remediation
The plan names where issues are tracked. This is typically an accessibility compliance management platform or a ticketing system already used by the engineering team. Each issue should carry a WCAG reference, the affected location, a severity rating, and a recommended fix.
Prioritization rules belong in the plan. User impact and legal risk are the two dimensions most organizations use. High-impact issues affecting core flows (checkout, account creation, contact forms) are remediated first. Lower-impact issues on rarely visited pages move further down the queue but stay in the backlog.
Include Training and Accessibility Statement Updates
Training is part of maintenance because the people producing content change. Document what training each role receives, how often it is refreshed, and how new hires are onboarded. Developers, designers, content authors, and QA reviewers each need role-specific material.
The accessibility statement is a living document. The plan describes who updates it, on what schedule, and what events prompt a revision (a new audit, a remediation milestone, a change in conformance target).
Review the Plan Itself
A maintenance plan that is written once and never revisited becomes inaccurate within a year. Set a review cadence for the document, typically annually, and record the last revision date inside the plan. When ownership changes, when the conformance target changes, or when a new property comes online, the plan is updated to match.
A working plan is short enough to read in fifteen minutes and specific enough that a new team member could follow it without asking questions.