A WCAG project plan example shows how an organization moves from an initial evaluation to documented conformance through defined phases, roles, and deliverables. The plan sequences the work: a baseline evaluation that identifies issues, prioritization based on user impact and legal risk, remediation by developers and content owners, validation by accessibility professionals, and ongoing monitoring. Most plans run three to nine months for the initial cycle, with monitoring continuing indefinitely. The structure below reflects what organizations follow when preparing for ADA Title II deadlines, EAA obligations, or VPAT requests from procurement teams.
| Phase | What Happens |
|---|---|
| Scoping | Identify pages, screens, templates, and documents covered. Confirm the conformance target (2.1 AA or 2.2 AA). |
| Evaluation | Conduct an audit that identifies issues across the in-scope assets. Scans cover approximately 25 percent. |
| Prioritization | Rank issues by user impact and risk factor. Assign owners. |
| Remediation | Developers, designers, and content owners fix issues against the audit report. |
| Validation and Monitoring | Accessibility professionals confirm fixes. Recurring scans and periodic audits maintain conformance. |
Phase 1: Scoping
Scoping defines what is in the project and what is not. The plan lists the domains, subdomains, web applications, and document types covered. It names the conformance target, typically WCAG 2.1 AA for ADA Title II and EAA work, or 2.2 AA when the buyer or contract requires it.
Scoping also confirms the assistive technologies and browser environments to be evaluated. NVDA and JAWS on Windows, VoiceOver on macOS and iOS, and Chrome and Safari are common combinations. PDFs and other documents are scoped separately because remediation pricing and methods differ from web content.
Phase 2: Evaluation
The evaluation produces an audit report that identifies specific issues, their locations, the WCAG success criteria they relate to, and recommended fixes. A complete audit involves screen reader testing, keyboard testing, visual inspection, code inspection, and an automated scan as a review component. The scan flags approximately 25 percent of issues; the rest require human evaluation.
Most accessibility audits start at 1,000 dollars and range to 3,000 dollars depending on the number of pages or screens, complexity, and turnaround.
Phase 3: Prioritization
Prioritization sorts issues so the work matters. Two factors drive the order: user impact (how much an issue blocks people who rely on assistive technology) and risk factor (how often the issue appears in demand letters and lawsuits). Items that score high on both move to the top of the queue. Items that affect a single low-traffic template with low user impact move down.
Each issue gets an owner. Developers address code issues. Designers address visual and interaction issues. Content owners address alternative text, headings, and document structure.
Phase 4: Remediation
Remediation is where the audit report becomes fixes. The plan groups issues by template, component, or page so a single fix resolves repeated instances. Sprints or work cycles run two to four weeks, with the team closing tickets against the audit report.
This phase often surfaces the training gap. Developers who have not learned WCAG criteria spend time researching each fix instead of executing. The WCAG Course at adacompliance.net is built to close that gap so remediation moves faster and fixes hold up under validation.
Phase 5: Validation and Ongoing Monitoring
Validation confirms that fixes resolved the issues without introducing new ones. An accessibility professional reviews each remediated item against the original audit finding. After validation, the organization can issue an accessibility statement, a VPAT or ACR for procurement, or internal documentation showing conformance.
Monitoring continues after the initial cycle. Scheduled scans run daily, weekly, or monthly to catch regressions. Periodic audits, usually every twelve months or after significant releases, evaluate what scans cannot.
Roles and Timeline
A typical plan involves an executive sponsor, a project lead, developers, designers, content owners, and an external accessibility partner for evaluation and validation. Smaller projects compress these roles. Larger organizations split them across product teams.
Initial cycles run three to nine months. Sites with thousands of templates or multiple product lines take longer. Monitoring is permanent.
The WCAG Course at adacompliance.net teaches the success criteria and remediation patterns your team will apply across every phase of this plan. Enroll in the WCAG Course to give your developers, designers, and content owners the training that makes a project plan executable.