Back to reviews and guides

How Long Does WCAG Compliance Take?

WCAG compliance time varies by site size, codebase and content type. This guide breaks down the phases, main factors that change timelines, a repeatable estimation method, common delays and practical steps to speed up compliance.

How Long Does WCAG Compliance Take?

How long does web accessibility and WCAG compliance take depends on the site and the target level. A small static site might be compliant in a few weeks, while a complex web application can take many months. Below is a practical guide to the stages, the main factors that change the timeline, and a reproducible method to produce an accurate estimate for your project.

Quick answer: realistic timeline ranges

Use these as rough planning ranges, not guarantees:

  • Small brochure site (fewer than 50 pages): a few weeks to a couple of months.
  • Medium site or ecommerce (hundreds of pages, product feeds): 2 to 6 months.
  • Large site or complex web app (thousands of pages, SPA, custom widgets): 3 to 12+ months.

These ranges cover discovery, fixes, developer QA, assistive-technology testing and stakeholder sign-off. They assume one active accessibility project team rather than ad hoc fixes.

Major factors that change the timeline

Site size and page count

More pages mean more reviews and more code changes. A single template that serves many pages is faster to fix than many unique templates.

Codebase and architecture

Content management systems with standard themes are quicker to remediate. Single page applications and heavy client-side rendering require more manual testing and ARIA work.

Custom components and third-party embeds

Widgets, maps, video players and payment flows often need custom work or vendor negotiation. Third-party code can be a major blocker.

Multimedia and documents

Video captions, audio transcripts and accessible PDFs take separate time and workflows. Bulk content remediation can add weeks.

Current accessibility maturity

If developers already use semantic HTML, labels and keyboard focus rules, remediation is faster. If accessibility is new, training and process changes add time.

Public-sector or regulated projects with a formal legal deadline may require accelerated timelines and prioritised fixes. In the UK public bodies must meet the Public Sector Bodies Accessibility Regulations 2018, which reference WCAG 2.1 AA as the expected standard for most content.

Typical compliance phases and what each takes

1. Discovery and scoping (1 week to 4 weeks)

Set the target WCAG level, list pages and identify priority user journeys. Deliverables: scope document, sample page list, success criteria and a remediation backlog.

2. Automated scanning and baseline report (days to 2 weeks)

Run tools such as axe, WAVE and Lighthouse to find obvious failures. Automated tools catch 20 to 50 percent of issues but miss many ARIA, focus order and semantics problems. The baseline report provides a first backlog and rough sizing.

3. Manual review and expert audit (1 to 6 weeks)

Experts check keyboard navigation, forms, labels, color contrast, semantics and ARIA. They also sample assistive-technology workflows. Manual review converts automated findings into actionable fixes and estimates effort per task.

4. Remediation and development sprinting (weeks to months)

Developers implement fixes in the codebase. Work is easiest when tracked as tickets and prioritised by impact on users and legal risk. Expect iterative cycles: fix, developer QA, regression testing.

5. Assistive-technology and user testing (1 to 4 weeks)

Testing with screen readers, keyboard-only users and people with disabilities finds real-world problems that tools miss. Include at least a small user test for each major flow.

6. Sign-off, accessibility statement and monitoring (1 to 2 weeks)

Draft an accessibility statement that lists the WCAG target and known issues. Put monitoring in place for future pages and add accessibility to QA pipelines.

Example timelines by project type

Project type Typical total time Main drivers
Small brochure site Weeks Few templates, limited multimedia
Medium site or ecommerce 2 to 6 months Product pages, search, carts, PDFs
Large app or enterprise site 3 to 12+ months Custom widgets, SPAs, integration points

An example estimation method you can use (practical information gain)

Competitors often give ranges but not a repeatable method. Use this simple model to translate site audit results into a time estimate for your stakeholders.

  1. Classify pages by complexity: low, medium, high. Low = mostly text and images. Medium = forms, interactive lists, tables. High = complex widgets, maps, custom controls.
  2. From the manual audit, record the number of sample pages in each class and average remediation tasks per page.
  3. Apply example remediation hours per page to produce an hours estimate. For planning use conservative values: low 1 to 3 hours, medium 3 to 8 hours, high 8 to 20 hours. Adjust based on your codebase and developer experience.
  4. Add fixed time for discovery, user testing and project management (typical 20 to 30 percent of remediation hours).

This gives a defensible estimate you can share with managers. Always run a short pilot: remediate 3 to 10 pages to validate the model before committing to a full rollout.

Common mistakes that add weeks to a project

  • Fixing low-impact issues first instead of critical user journeys.
  • Relying only on automated tools and skipping manual checks.
  • No clear ownership. Accessibility needs a product or engineering owner with time to review pull requests.
  • Waiting until the end to test with assistive-technology users.
  • Ignoring third-party components such as payment flows or advertising widgets.

How to speed up the process without risking quality

  • Prioritise by impact: fix login, search, checkout and forms first.
  • Use component-level fixes so a single change fixes many pages.
  • Run accessibility checks in CI so regressions are caught early.
  • Train at least two developers on WCAG 2.1 AA patterns and WAI-ARIA basics.
  • Use a mix of automated scans and short, focused manual tests on every sprint.

What to include in a scope to get accurate vendor quotes

  • Target WCAG level (for example WCAG 2.1 AA).
  • Number of unique templates and sample pages per template.
  • List of third-party integrations and document types (PDFs, video).
  • Required deliverables: audit report, remediation tickets, user testing, accessibility statement, training session.
  • Acceptance criteria for sign-off.

Testing types and who should be involved

  • Automated testing. Good for regressions and quick scanning.
  • Manual expert review. Finds semantics and ARIA issues that tools miss.
  • Assistive-technology testing. Screen readers (NVDA, JAWS, VoiceOver) and keyboard only testing.
  • Real user testing. People with a range of disabilities using key journeys.

Ongoing monitoring and governance

Accessibility is not a one-off project. Put these in place to avoid backsliding:

  • Automated checks in CI for new pages and builds.
  • Accessibility criteria in design and code reviews.
  • Quarterly spot audits and an annual full audit.
  • Training for product owners and designers.

Next steps checklist

  • Decide target WCAG level and deadline.
  • Create a sample set of pages and run an automated scan.
  • Commission a short expert audit to size the work.
  • Run a 2 to 4 week pilot to validate remediation rates.
  • Prioritise critical user journeys and start sprints focused on those.

Use the model and checklist above to turn vague timelines into a clear plan. That will help you give stakeholders an accurate estimate and reduce the chance of late surprises.