Plan a WCAG 2.2 AA Remediation Project
To plan a WCAG 2.2 AA remediation project, start with a recent audit report that identifies issues across representative pages and templates, then prioritize those issues by user impact and legal risk, assign ownership to the right teams, set a realistic schedule, and build in validation and monitoring after fixes are made. Remediation is the work that follows an evaluation, and the quality of the plan determines whether the work actually moves a site toward conformance.
| Element | What It Covers |
|---|---|
| Scope | Pages, templates, components, documents, and authenticated areas included in the project. |
| Source data | A current audit report identifying issues, with locations and remediation guidance. |
| Prioritization | Ordering issues by user impact and risk factor, not by ease of fixing. |
| Ownership | Clear assignment of issues to developers, designers, content authors, and vendors. |
| Validation | Re-evaluation of fixed issues to confirm conformance before closing them out. |
Start With a Current Audit Report
A remediation project is only as good as the data behind it. Scans alone are not sufficient because they detect approximately 25% of accessibility issues. The other 75% requires a manual audit conducted by accessibility professionals using screen reader testing, keyboard testing, visual inspection, and code inspection.
The audit report should identify each issue, the WCAG 2.2 AA success criterion it relates to, the location, and recommended remediation guidance. Without this level of detail, the project team cannot plan accurately or estimate the work involved.
Define Scope Before Estimating Work
Scope sets the boundaries of the project. A site with five core templates and a marketing blog is a different project than a site with authenticated dashboards, a checkout flow, and downloadable PDFs. Decide upfront whether documents, third-party components, and authenticated pages are included.
Most accessibility audits start at 1,000 dollars and range to 3,000 dollars depending on scope, and remediation effort scales with the number and complexity of issues identified. Knowing what is in and out of scope early prevents the project from expanding mid-engagement.
Prioritize by User Impact and Risk Factor
Not every issue carries equal weight. A keyboard trap on a checkout page affects more users and carries more legal exposure than a minor labeling inconsistency on a rarely visited page. Prioritization should account for both how much an issue affects people using assistive technologies and how much it contributes to legal risk.
A common ordering looks like this:
- High impact, high risk: keyboard operability, form labels, focus management, and alternatives for non-text content on primary user paths.
- High impact, lower risk: issues that affect specific user groups but appear on lower-traffic pages.
- Lower impact, lower risk: cosmetic or edge-case items that should still be remediated but do not block the project.
Assign Ownership Across Teams
Remediation rarely belongs to one team. Developers fix code-level issues. Designers update components and patterns so the same problems do not return. Content authors revise alt text, headings, and link text. Procurement teams coordinate with third-party vendors whose embedded components are out of the internal team’s direct control.
Each issue in the audit report should map to a specific owner. Issues without owners stall, and stalled issues are how projects miss deadlines.
Set a Realistic Schedule
Schedules should reflect both the volume of issues and the team’s capacity to absorb the work alongside existing roadmap commitments. Treating remediation as a side project produces inconsistent results. Treating it as a defined workstream with milestones produces measurable progress.
Build the schedule around prioritized batches. The highest impact and risk items go first, followed by the next tier, and so on. This sequencing reduces risk earlier in the project rather than at the end.
Validate Fixes Before Closing Issues
Fixes must be re-evaluated. A developer marking an issue as resolved is not the same as confirming the fix actually meets the relevant success criterion. Validation involves re-evaluating with assistive technologies, re-inspecting the code, and confirming the user-facing experience works as intended.
Without validation, projects produce a clean ticket queue but a site that still does not conform. Validation is what closes the loop between remediation work and WCAG 2.2 AA conformance.
Plan for Monitoring After the Project
A site that conforms today will drift out of conformance as new content is published, components are added, and third-party scripts change. Plan for ongoing monitoring through scheduled scans and periodic re-evaluation of high-traffic templates. Monitoring catches regressions before they accumulate into another full remediation cycle.
Document the Work
Documentation of what was evaluated, what was fixed, when it was fixed, and how it was validated supports an accessibility statement and demonstrates a sustained effort toward conformance. This documentation is also what allows the next team or vendor picking up the work to continue without starting from scratch.
A well-planned WCAG 2.2 AA remediation project is less about heroic fixes and more about steady, ordered progress against a credible audit report.