Website Accessibility Audit: The Complete Guide (WCAG 2.2)

A website accessibility audit is a structured review of a website against the Web Content Accessibility Guidelines (WCAG) — the technical standard cited by the ADA (United States), the EAA (European Union, June 2025), and Section 508 (US federal). Done properly, an audit produces two things you can actually use: a prioritized list of issues to fix, and dated evidence that you are conforming on an ongoing basis. This guide explains what an audit covers, who needs one, what tools and methods exist, and what the deliverable should look like.

What an audit actually checks

WCAG 2.2 has 86 success criteria across four principles: Perceivable, Operable, Understandable, Robust. An audit checks each criterion that applies to your pages, at the conformance level you target (A, AA, or AAA). Most legal contexts target WCAG 2.2 Level AA — that is what the ADA case law and EAA technical specifications converge on.

For each criterion, the audit answers three questions:

• Does this criterion apply? (e.g., 1.2.2 Captions only applies if you have pre-recorded video)
• Are you passing? If yes, document the evidence (which page, which element, which check).
• If failing, what is the severity? Critical / Serious / Moderate / Minor — driven by user impact and legal exposure.

Who needs an audit

Three groups commonly trigger an audit:

1. Sites that received an ADA demand letter or a settlement notice. The audit is the first artefact your counsel will ask for. See our 72-hour ADA demand-letter playbook.
2. EU-facing businesses preparing for the European Accessibility Act (enforcement started June 28, 2025). Even non-EU companies trading into the EU above defined thresholds are in scope. See EAA 2025 requirements.
3. SaaS and ecommerce teams responding to procurement. Enterprise buyers, government, education, and healthcare procurement increasingly attach a VPAT request (or its EU equivalent, a Conformance Report) to their RFP. See how to produce a VPAT.

Automated vs manual vs user testing

Industry consensus is that automated tools catch 30 to 50 percent of WCAG failures. The exact figure depends on the site — heavy on forms and dynamic widgets, automated coverage drops; mostly static text content, automated coverage peaks. The remaining 50 to 70 percent requires manual checks: keyboard-only navigation, screen reader walk-throughs, 400% zoom layout, focus management on modals and drawers, cognitive load on error states and form recovery. The last 5 to 10 percent — checks like "is the workflow understandable to a screen reader user under time pressure" — only emerges from user testing with people who actually rely on assistive technology.

A reasonable audit balances all three layers. Automated runs continuously (CI on every deploy, plus a scheduled scan), manual is done quarterly or per major release, user testing is done annually or for new flagship features. The step-by-step workflow we use covers the manual layer in detail.

Tools we actually use

• Automated — axe-core via AccessProof (continuous), Lighthouse, WAVE for spot checks. axe-core has the lowest false-positive rate of the open-source engines. See axe-core vs Lighthouse.
• Keyboard — Tab, Shift+Tab, Enter, Space, Esc, arrow keys. Every interactive element must be reachable and operable. No keyboard traps. Focus indicators visible.
• Screen reader — NVDA (Windows, free), VoiceOver (macOS / iOS, built-in), JAWS (Windows, dominant in enterprise) on at least Chrome and Safari. Basics here.
• Color contrast — automated for normal text and UI, manual review of brand colors and adjacent surfaces. Free contrast checker.
• Zoom & reflow — 400% zoom in a 1280-wide viewport. Content must reflow to one column, no horizontal scrolling except for data tables.

What the deliverable should look like

A defensible audit report contains:

• Date and scope — which URLs were audited, which standard and conformance level was targeted, when (timestamps matter — they bound the plaintiff's claims).
• Methodology — automated tools used (with version), manual checks performed, assistive technology versions tested.
• Per-criterion finding — pass / fail / not applicable, with evidence for each failure (selector, screenshot, expected behavior).
• Severity-ranked remediation list — Critical and Serious first, with effort estimate and owner.
• Re-test plan — when the next audit happens, what the cadence is. Continuous improvement is what most plaintiff firms settle around.

How often to audit

Three rhythms run in parallel:

• Continuous (automated) — every deploy. Catches regressions before they ship. AccessProof Starter covers 5 sites weekly; Pro covers 25 sites daily; Business covers unlimited hourly.
• Quarterly (manual + automated) — a human walks the critical flows on top of the continuous scans.
• Annually (full audit + user testing) — comprehensive, all pages, all flows, with assistive technology users where budget allows.

Cost and effort

An automated baseline scan is essentially free (we run them under a minute on our infrastructure for $0 on the Free plan). A manual quarterly review by an internal team typically takes 8 to 24 hours per site depending on complexity. A full external audit by a specialist agency runs $5k to $25k per site, more for SPAs and dashboards. The math almost always favours running automated continuously and reserving manual / specialist time for the criteria automation cannot cover.

Common mistakes

• Auditing once and shipping it. An audit dated more than 90 days ago is stale evidence — the site has likely changed underneath it. Continuous beats one-shot.
• Ignoring focus management. Modals, drawers, and dynamic content are where most lawsuits originate. Automated tools rarely catch focus-trap failures.
• Color contrast on hover and disabled states. The default state passes, the interactive states fail. Audit every state, not just resting.
• Forms without programmatically associated labels. Placeholder text is not a label. We see this on roughly 40% of new audits.
• Relying on an overlay widget. Why overlays are a documented liability.

Where to start

If you have not run any kind of accessibility check on your site, start with the smallest commitment that produces dated evidence: run a free WCAG 2.2 scan on any URL. You get a compliance score, the four-tier severity breakdown, and the top five issues — no signup, no overlay, no marketing loop. Use that as the baseline against which to plan the rest of the audit work. For continuous monitoring across multiple sites, the Starter plan ($29/mo) covers 5 sites with weekly scans and PDF reports; Pro and Business escalate to daily and hourly cadence.

Once you have a baseline, walk the 7-step manual workflow on your three most critical flows: signup, checkout (or primary conversion), and the dashboard or member area. Those three flows are what plaintiff firms screenshot in demand letters. Fix the Critical and Serious findings first. Document each fix with a date, a commit, and the next re-scan result that confirms it. That documented sequence — issue identified, fix shipped, re-scan green — is the contemporaneous evidence the ADA and EAA processes expect.