Most accessibility projects take between 2 and 12 months from audit through remediation and validation. The actual timeline depends on a few core variables: how many digital assets are in scope, how many issues the audit identifies, how quickly your development team can address fixes, and whether you need an ACR or certification documents at the end.
There is no universal number. But there is a reliable way to build your own estimate using the variables that actually drive project length.
| Factor | Impact on Timeline |
|---|---|
| Number of digital assets | More websites, apps, or platforms in scope means more audits, more issues, and more remediation cycles |
| Complexity of each asset | A web app with dynamic forms and custom components takes longer than an informational website |
| Volume of issues identified | A first-time audit often identifies hundreds of issues across pages and templates |
| Developer capacity | Remediation speed is directly tied to how many hours per week your team can dedicate to fixes |
| Validation and re-evaluation | An auditor must verify that fixes achieve WCAG conformance, adding 1 to 3 weeks per cycle |
| Deliverables needed | If the project includes an ACR (completed VPAT), user evaluation, or certification, each adds time |
What Phases Make Up an Accessibility Project?
An accessibility project follows a predictable sequence. Knowing the phases makes it easier to estimate how long an accessibility project will take because you can assign rough timeframes to each one.
Inventory: Cataloging all digital assets that need to be evaluated. For a single website, this might take a day. For an organization with multiple web apps, mobile apps, and a CRM, it could take a week or more.
Audit: A manual evaluation against the WCAG 2.1 AA or WCAG 2.2 AA standard. Turnaround time depends on scope. Accessible.org typically delivers audit reports within 2 to 4 weeks for most projects.
Remediation: Developers fix the issues the audit identifies. This is almost always the longest phase. A small informational website might need 2 to 4 weeks. A complex web app or platform can require 2 to 4 months of dedicated development time.
Validation: The auditor re-evaluates the asset to confirm fixes meet WCAG conformance. This typically adds 1 to 3 weeks.
Documentation: If you need an ACR, accessibility statement, or certification documents, factor in another 1 to 2 weeks after validation is complete.
How Asset Type Affects Your Timeline
A 20-page informational website is a different project than a SaaS platform with 80 unique screens. The type of digital asset shapes every phase.
Informational websites with mostly static content tend to move through the full cycle in 6 to 10 weeks. The audit is faster, issues are often template-level (meaning one fix corrects many pages), and remediation is simpler.
Web apps, mobile apps, and ecommerce platforms carry more complexity. Custom components, dynamic content, and interactive workflows all increase the number of issues an audit identifies. Remediation takes longer because each component may require individual attention. These projects typically run 3 to 6 months from audit through validation.
If your project includes multiple assets, like a website and a mobile app, plan for overlapping timelines rather than sequential ones. You can audit both concurrently, but remediation will depend on team bandwidth.
Remediation Is Where Timelines Expand or Compress
The audit itself has a relatively predictable turnaround. Remediation is where estimates get uncertain.
Three things determine remediation speed:
First, the number of issues. A first-time audit on a medium-sized website can identify 100 to 300 individual issues. Many of those will be pattern-based (the same issue appearing across multiple pages), which means one code change resolves many instances. But some issues are unique to specific pages or components.
Second, developer familiarity with accessibility. A team that has worked through WCAG requirements before will move faster. A team doing this for the first time may need a few weeks to ramp up. Accessible.org offers digital accessibility training for organizations that helps teams get productive sooner.
Third, how many hours per week the team can allocate. A developer spending 20 hours per week on remediation will finish in roughly half the time compared to one spending 10 hours. This sounds obvious, but it is the single biggest variable in most project timelines. Organizations that treat accessibility as a side task see their projects stretch to 6 months or longer.
How to Build a Realistic Estimate
Start with the audit. If you have not yet completed one, your timeline estimate is inherently rough. The audit report is what gives you the data to plan remediation with confidence.
Before the audit, you can still build a ballpark using these benchmarks:
For a single informational website (under 30 pages): plan for 6 to 10 weeks total. That breaks down to roughly 2 weeks for the audit, 3 to 6 weeks for remediation, and 1 to 2 weeks for validation.
For a web app or SaaS product (20 to 60 screens): plan for 3 to 5 months. Audit turnaround of 2 to 4 weeks, remediation of 8 to 14 weeks, and validation of 2 to 3 weeks.
For a large platform or multiple assets: plan for 4 to 8 months. These projects benefit from phased approaches where high-priority sections are addressed first.
Once the audit report is delivered, you can refine these numbers. The Accessibility Tracker Platform helps project managers track issue volume, assign priorities using Risk Factor and User Impact prioritization formulas, and monitor remediation progress in real time. That visibility makes it possible to give leadership accurate completion forecasts rather than guesses.
Does the WCAG Standard Version Change the Timeline?
Marginally. WCAG 2.2 AA is the newer standard, and some organizations are adopting it for procurement or compliance reasons. An audit against WCAG 2.2 AA covers additional criteria compared to WCAG 2.1 AA, which can add a small number of issues to the report.
The difference in project length between the two versions is typically a week or two, not months. Choose the version that aligns with your compliance requirements (ADA compliance, Section 508, EN 301 549, or EAA compliance), and plan accordingly.
What About Projects That Include a VPAT?
If your project requires an ACR (the completed document produced from the VPAT template), factor that into the back end of your timeline. The ACR is generated after the audit. If your goal is a clean ACR with full WCAG conformance, you will want to complete remediation and validation first.
The VPAT and ACR process typically adds 1 to 2 weeks after the audit or re-evaluation is finalized. For organizations in procurement cycles, it helps to work backward from the ACR delivery deadline to set the project start date.
Common Reasons Projects Take Longer Than Expected
Developer availability drops. This is the most frequent cause. When accessibility work competes with feature development, it loses priority and the timeline stretches.
Scope expands mid-project. An organization discovers additional digital assets that need to be included, or a redesign launches during remediation that introduces new issues.
No tracking system. Without a way to monitor which issues have been fixed and which remain, teams lose visibility into progress. Projects without structured tracking tend to take 30 to 50% longer. Accessible.org recommends using a dedicated tracking approach, whether through the Accessibility Tracker Platform or a well-organized spreadsheet.
No re-evaluation planned. Teams sometimes assume fixes are correct without having an auditor verify conformance. Skipping validation means the project is never truly complete, and issues persist without anyone knowing.
How Do Scans Fit Into the Timeline?
Automated scans are a separate activity from auditing. Scans can be conducted at any point during the project to flag surface-level issues (scans only flag approximately 25% of issues). They are useful for monitoring progress between evaluation cycles, but they do not replace the audit or shorten it.
Some teams conduct scans before the audit to get a general sense of their current state. Others use scans during remediation to confirm that automated checks pass before requesting validation from the auditor. Neither approach changes the overall project duration significantly, but both can improve efficiency.
An accessibility audit conducted by a qualified auditor is the only way to determine WCAG conformance. Scans supplement that process.
Can I speed up an accessibility project?
Yes. The fastest path is dedicating more developer hours per week to remediation. Prioritizing template-level fixes first also produces the biggest conformance gains early. Using the Accessibility Tracker Platform to organize and assign issues can reduce coordination overhead by days or weeks.
How long does remediation take for a Shopify store?
Most Shopify websites need 3 to 6 weeks of remediation after the audit, depending on theme complexity, the number of apps in use, and how many custom elements exist. Stores with minimal customization trend toward the shorter end.
Should I plan for ongoing accessibility work after the project?
Yes. Accessibility is not a one-time project. Any time content is added, features change, or the platform updates, new issues can appear. Budget for periodic re-evaluation, ongoing monitoring through scans, and accessibility services to maintain conformance over time.
Building a reliable project timeline starts with understanding your scope and getting an audit completed. Everything after that becomes a math problem, not a guessing game.
Contact Accessible.org to discuss your project scope and timeline.
