TL;DR: A website accessibility audit is a structured evaluation of your site against WCAG 2.2 Level AA success criteria, combining automated scanning with manual testing and assistive technology validation. Expect to pay $3,000–$30,000+ depending on site complexity, receive a prioritized findings report with remediation guidance, and budget 2–8 weeks for the process. If you accept payments, serve the public, or operate in a regulated industry, you almost certainly need one.

What Is a Website Accessibility Audit?

A website accessibility audit is a systematic evaluation of a website's design, code, and content against established accessibility standards -- primarily the Web Content Accessibility Guidelines (WCAG) 2.2 at Level AA conformance -- to identify barriers that prevent people with disabilities from using the site. The audit combines automated tool scanning, manual expert review, and assistive technology testing to produce a prioritized report of issues and a remediation plan.

That definition matters because the term "audit" gets thrown around loosely. Running axe DevTools on your homepage is not an audit. An overlay vendor telling you your site is "compliant" is not an audit. An audit is a methodical, documented process with defined scope, criteria, and deliverables.

The W3C's Web Accessibility Initiative (WAI) lays out the evaluation framework in their Test & Evaluate overview. Their approach distinguishes between easy checks anyone can run, tool-assisted evaluation, and conformance evaluation involving human judgment. A real audit sits squarely in that third category -- conformance evaluation -- with tools supporting the process rather than driving it.

Who Needs a Website Accessibility Audit?

Almost every organization with a public-facing website has a legal, ethical, or business reason to conduct one.

You're Legally Required to Audit If:

Federal agencies and contractors must comply with Section 508 of the Rehabilitation Act, which requires federal electronic and information technology to be accessible. The current Section 508 standards reference WCAG 2.0 Level AA, though agencies are increasingly aligning with WCAG 2.1 and 2.2.

State and local governments face a DOJ final rule published in April 2024 under ADA Title II requiring websites to conform to WCAG 2.1 Level AA, with compliance deadlines starting April 2026 for larger entities and April 2027 for smaller ones.

Private businesses that operate places of public accommodation fall under ADA Title III. While the statute doesn't explicitly mention websites, federal courts have increasingly held that websites of businesses with physical locations -- and sometimes purely online businesses -- fall under Title III. There is no single federal standard yet for private-sector web accessibility, but WCAG 2.1 AA has become the de facto benchmark courts and settlement agreements reference.

Organizations receiving federal funding must comply with Section 504 of the Rehabilitation Act.

Companies operating in the EU need to meet the European Accessibility Act (EAA), which takes effect June 28, 2025, requiring accessibility for a range of digital products and services.

You Should Audit for Business Reasons If:

You run an e-commerce site. Accessibility barriers directly reduce your addressable market. The CDC reports that roughly 1 in 4 adults in the United States has some type of disability.

You sell B2B SaaS to government. Procurement teams will ask for a VPAT (Voluntary Product Accessibility Template). Without one, you're out of the running.

You've received a demand letter. If you've gotten a legal demand or complaint about accessibility, an audit is step one in building your response and remediation plan.

What Does a Website Accessibility Audit Test Against?

WCAG 2.2 Level AA is the current standard. It includes 55 success criteria across four principles: Perceivable, Operable, Understandable, and Robust.

The W3C maintains a WCAG 2.2 Quick Reference that lets you filter by level and topic. Here's what the criteria cover:

Perceivable

Area Example Criteria What's Tested
Text alternatives 1.1.1 Non-text Content Every image, icon, chart, and CAPTCHA has appropriate alt text or is marked decorative
Time-based media 1.2.1–1.2.5 Videos have captions, audio descriptions where needed
Adaptable 1.3.1–1.3.6 Semantic HTML structure, reading order, orientation not locked
Distinguishable 1.4.1–1.4.13 Color contrast (4.5:1 for normal text, 3:1 for large text), text resize to 200%, reflow at 320px, text spacing adjustments

Operable

Area Example Criteria What's Tested
Keyboard 2.1.1–2.1.4 All functionality works via keyboard, no keyboard traps, character key shortcuts can be remapped
Enough time 2.2.1–2.2.2 Time limits can be adjusted, auto-playing content can be paused
Seizures 2.3.1 No content flashes more than 3 times per second
Navigable 2.4.1–2.4.13 (new in 2.2) Skip links, page titles, focus order, link purpose, focus appearance
Input modalities 2.5.1–2.5.8 Pointer gestures have alternatives, dragging has alternatives (new in 2.2), target size minimum 24x24 CSS pixels

Understandable

Area Example Criteria What's Tested
Readable 3.1.1–3.1.2 Page language declared, language of parts declared
Predictable 3.2.1–3.2.6 No unexpected context changes on focus or input, consistent navigation, consistent help location (new in 2.2)
Input assistance 3.3.1–3.3.9 Error identification, labels, error prevention, redundant entry minimized (new in 2.2), accessible authentication (new in 2.2)

Robust

Area Example Criteria What's Tested
Compatible 4.1.2–4.1.3 Name, role, value for all UI components, status messages announced to assistive tech

WCAG 2.2 added 9 new success criteria compared to 2.1, including Focus Appearance (2.4.13), Dragging Movements (2.5.8), Consistent Help (3.2.6), Redundant Entry (3.3.7), and Accessible Authentication (3.3.8/3.3.9). If your last audit was against 2.1, you have gaps to close. WCAG 2.2 also removed success criterion 4.1.1 (Parsing) because modern HTML specifications and browser behavior made it obsolete.

Automated Scanning vs. Manual Audit: What's the Real Difference?

Automated scanning catches roughly 30–40% of WCAG issues. That number comes up consistently across the industry. The rest requires human judgment.

What Automated Tools Catch

Automated tools excel at detecting missing alt attributes (though they can't judge whether alt text is accurate), color contrast failures against mathematical thresholds, missing form labels, duplicate IDs, missing language attributes, ARIA attribute validity (correct roles, required properties), and they can scan large numbers of pages quickly -- thousands of URLs in minutes.

Popular automated tools include axe-core (Deque, free and open source), WAVE (by WebAIM, available as a browser extension and API), Lighthouse (built into Chrome DevTools), Pa11y (open source, CI-friendly), and commercial platforms like Siteimprove, Level Access, and TPGi's ARC Toolkit.

The W3C maintains a Web Accessibility Evaluation Tools List with over 160 entries.

What Automated Tools Miss

They cannot judge whether alt text is meaningful -- an image with alt="IMG_3847.jpg" passes an automated check for presence but fails the actual WCAG requirement. They can't evaluate reading order and content structure for screen reader users. They can't test keyboard interaction patterns for custom widgets like accordions, modals, date pickers, or tab panels. They can't detect focus management issues after dynamic content changes (does focus move to the modal when it opens?). They can't assess whether error messages are helpful and properly associated. They can't verify that ARIA patterns match user expectations -- you can have valid ARIA that creates a terrible user experience. And they can't test with actual assistive technology like screen readers or voice control.

The most impactful barriers -- a checkout flow that traps keyboard users, a form that doesn't communicate errors to screen readers, a modal that steals focus and never gives it back -- almost always require manual testing to find. An automated-only audit gives you a false sense of compliance. It's like running a spell checker on a legal contract and calling it reviewed.

The Right Approach: Automated + Manual + Assistive Technology

A credible audit uses all three:

  1. Automated scanning to establish a baseline and catch the low-hanging issues across a broad page sample
  2. Manual expert review of representative pages and user flows by someone who understands WCAG criteria and can exercise judgment
  3. Assistive technology testing with actual screen readers (NVDA, JAWS, VoiceOver), keyboard-only navigation, voice control, and screen magnification

What Does an Assistive Technology Audit Actually Look Like?

Assistive technology (AT) testing means an auditor uses the same tools that people with disabilities use daily and attempts to complete real tasks on your site. This isn't theoretical -- it's hands-on.

A typical AT testing protocol includes:

Screen reader testing: Navigate the site using NVDA (free, Windows) with Firefox, JAWS (Freedom Scientific, ~$1,000/year license) with Chrome, and VoiceOver (built into macOS/iOS) with Safari. Each combination surfaces different issues because screen readers interpret code differently.

Keyboard-only navigation: Tab through every interactive element. Can you reach everything? Can you activate everything? Can you always see where focus is? Can you escape menus and modals?

Zoom and magnification: Enlarge to 200% and 400%. Does content reflow? Do you lose functionality? Does anything overlap or get clipped?

Voice control testing: Use Dragon NaturallySpeaking or Voice Control (macOS) to interact with forms and links. Are clickable elements properly labeled so voice users can reference them?

Reduced motion: Enable prefers-reduced-motion in OS settings and check that animations respect the preference.

This testing reveals the issues that matter most to actual users. We've seen sites pass automated scans with flying colors but become completely unusable the moment you turn on a screen reader -- custom dropdown menus that announce nothing, SPAs where page navigation isn't communicated, carousels that auto-advance with no way to pause them via keyboard.

What Deliverables Should You Expect?

A quality audit produces specific, actionable documentation. If a vendor delivers only a dashboard or a score, push back.

1. Detailed Findings Report

Each issue documented with:

  • WCAG success criterion violated (e.g., 1.4.3 Contrast Minimum)
  • Severity rating (Critical, Major, Minor -- or a 1–4 scale)
  • Location (URL, page area, component, CSS selector, or screenshot)
  • Description of the barrier and who it affects
  • How to reproduce the issue
  • Recommended fix with code examples where applicable

2. Executive Summary

A non-technical overview for stakeholders: how many issues found, breakdown by severity, highest-risk areas, and overall conformance status.

3. Remediation Roadmap

A prioritized plan for fixing issues, organized by:

  • Impact: How many users are affected and how severely
  • Effort: How complex the fix is (quick CSS change vs. rebuilding a component)
  • Pages/templates affected: Fixing a shared component like a global nav fixes every page at once

4. VPAT / ACR (When Requested)

A Voluntary Product Accessibility Template, formatted according to the ITI VPAT 2.5 template, documents your product's conformance with WCAG 2.x, Section 508, and/or EN 301 549 (the European standard). The completed document is technically called an Accessibility Conformance Report (ACR). B2B and government-facing products almost always need one.

5. Retest Plan

A defined scope and timeline for verification testing after remediation is complete. Some vendors include one round of retesting in the audit price; others charge separately.

How Much Does a Website Accessibility Audit Cost?

Pricing depends on site size, complexity, audit depth, and whether a VPAT is included. Here are realistic ranges based on what we've seen in the market as of 2024–2025:

Audit Type Scope Typical Cost What You Get
Automated scan only Entire site $0–$500/month Tool-generated report, no human review
Lightweight manual audit 5–15 key pages/flows $3,000–$8,000 Expert review + automated scan, findings report
Full manual + AT audit 15–50 pages/flows, AT testing $8,000–$25,000 Complete findings, remediation plan, executive summary
Enterprise audit + VPAT Complex app or large site, full VPAT $15,000–$35,000+ All deliverables, ACR, retesting
Ongoing monitoring Continuous scanning + periodic manual checks $500–$5,000/month Dashboard, alerts, quarterly manual reviews

Be cautious of audits priced below $2,000 for anything beyond a basic scan. A thorough manual review of even a small site requires 20–40 hours of expert time. At reasonable consulting rates ($125–$200/hour for senior accessibility specialists), the math doesn't work below that floor.

How Long Does a Website Accessibility Audit Take?

Timeline varies by scope:

Site Complexity Audit Duration Report Delivery
Small marketing site (10–20 pages) 1–2 weeks of active testing Report within 1 week after testing
Medium site with forms and interactive components (30–80 pages) 2–4 weeks of active testing Report within 2 weeks after testing
Large site or web application (100+ pages, complex flows) 4–8 weeks of active testing Report within 2–3 weeks after testing
VPAT creation Add 1–2 weeks on top of audit timeline --

Total elapsed time from kickoff to final deliverable is typically 3–10 weeks. Some of that time is spent in the scoping and scheduling phase before testing begins.

How to Choose an Accessibility Audit Provider

Not all audit providers are equal.

Look for Credentials and Expertise

IAAP certification: Look for auditors with CPWA (Certified Professional in Web Accessibility), CPACC, or WAS credentials from the International Association of Accessibility Professionals.

Assistive technology proficiency: Ask whether auditors are daily screen reader users or have formal AT testing training.

WCAG version: Confirm they test against WCAG 2.2, not 2.0 or 2.1. Some providers haven't updated their methodology.

Red Flags to Avoid

"100% compliance" guarantees: WCAG conformance is a point-in-time assessment. Any content change can introduce new issues. No vendor can guarantee perpetual compliance.

Overlay-only approaches: JavaScript overlay widgets that claim to fix accessibility automatically do not achieve WCAG conformance. They add a layer on top of broken code without fixing the underlying issues.

No manual testing included: If the audit is purely automated, it's a scan, not an audit.

Vague deliverables: Ask for a sample report before signing. If they can't show one (even redacted), that's a concern.

Questions to Ask Vendors

  1. What WCAG version and level do you audit against?
  2. How many pages/flows are included in the scope?
  3. Which screen readers and browsers do you test with?
  4. Who performs the testing, and what are their credentials?
  5. What does the final report look like? Can I see a sample?
  6. Is retesting included after we remediate?
  7. Do you produce VPATs/ACRs?
  8. How do you determine severity ratings?

WebAIM, the accessibility organization at Utah State University, offers both educational resources and professional evaluation services. Their WCAG 2 Checklist is one of the best plain-language translations of the WCAG success criteria. We often use it as a communication tool with clients who find the official WCAG specification dense. If you're evaluating audit providers, check whether they reference WebAIM's resources or the W3C's WAI directly -- it's a good signal of grounding in actual standards rather than marketing material.

What Happens After the Audit?

An audit without remediation is just an expensive document. Here's a practical post-audit workflow:

Triage findings by severity. Fix critical and high-severity issues first, especially those blocking entire user flows like checkout, signup, or login.

Fix template-level issues first. A contrast fix in your design system or a nav fix in your header component cascades across every page.

Integrate into your development process. Add accessibility acceptance criteria to your definition of done, configure axe-core or pa11y in your CI pipeline to catch regressions.

Schedule retesting. Verify fixes actually resolved the issues, especially AT-related findings.

Plan for ongoing monitoring. Accessibility is not a one-time checkbox. Content updates, new features, and third-party integrations introduce new barriers.

If your site is built on a CMS or a modern frontend framework, the audit findings often point to component-level fixes that benefit from headless architecture -- separating content from presentation gives you more control over the rendered HTML and ARIA attributes. We work through accessibility remediation at the component level across headless CMS implementations. You can see how we approach this at /capabilities/web-accessibility-compliance-wcag-ada.

FAQ

Is a website accessibility audit legally required?

There is no single federal law requiring private-sector websites to be audited. However, ADA Title III, Section 508, and state laws create accessibility obligations. An audit is the standard way to assess and document your compliance posture, and it's often the first step after receiving a demand letter or complaint.

Can automated tools replace a manual accessibility audit?

No. Automated tools catch approximately 30–40% of WCAG issues. They cannot evaluate content meaning, test keyboard interaction patterns for custom components, or verify screen reader behavior. A credible audit always includes manual expert review and assistive technology testing alongside automated scanning.

How often should we conduct an accessibility audit?

We recommend a full audit annually and after any major site redesign or platform migration. Between audits, run automated scans in your CI/CD pipeline and conduct periodic manual spot checks. Content-heavy sites with frequent updates may need semi-annual reviews.

What's the difference between WCAG 2.1 and WCAG 2.2?

WCAG 2.2, published as a W3C Recommendation in October 2023, adds 9 new success criteria to WCAG 2.1. Notable additions include Focus Appearance (2.4.13 AA), Dragging Movements (2.5.8 AA), Consistent Help (3.2.6 A), Redundant Entry (3.3.7 A), and Accessible Authentication (3.3.8 AA). It also removes criterion 4.1.1 Parsing.

What is a VPAT and do I need one?

A VPAT (Voluntary Product Accessibility Template) is a standardized document that declares your product's conformance with accessibility standards. The completed version is called an ACR (Accessibility Conformance Report). You need one if you sell software or services to government agencies or large enterprises that require accessibility documentation in procurement.

Do accessibility overlays count as compliance?

No. Overlay widgets do not fix underlying code issues and do not constitute WCAG conformance. The National Federation of the Blind and multiple advocacy organizations have publicly opposed overlays. Courts have not accepted overlay use as evidence of ADA compliance in cases we're aware of.

What happens if we find hundreds of issues in our audit?

This is normal, especially for sites that haven't been audited before. A good audit report includes severity ratings and a prioritized remediation roadmap. You don't fix everything at once -- you address critical barriers first, then work through major and minor issues systematically over weeks or months.

Can we do an accessibility audit ourselves?

You can run internal reviews using automated tools and the W3C WAI's evaluation methodology. However, without trained accessibility specialists and assistive technology testing experience, you'll miss significant issues. For compliance documentation or legal purposes, third-party audits carry more weight.