WCAG 2.2 Audit Guide · Updated May 2026
How to Audit a Website for Accessibility: A Step-by-Step WCAG 2.2 Guide
An accessibility audit is the difference between hoping your site is compliant and knowing it is. This guide walks through the exact nine-step process accessibility professionals use to audit a website against WCAG 2.2 Level AA — what to test, in what order, with which tools, and how to document findings that your development team can actually fix.
Skip the manual triage
Paste an issue, a code snippet, or a failing axe rule into the AI Accessibility Audit Helper and get a structured WCAG analysis — severity, user impact, technique IDs, and a copy-ready code fix — in under thirty seconds.
Open the AI Audit Helper →What an accessibility audit actually produces
A real accessibility audit is not a pass/fail score. It is a prioritized list of barriers — each tied to a specific WCAG 2.2 success criterion, a specific user impact, and a specific recommended fix. Audits are how organizations turn a vague "make the site accessible" ambition into engineering work that can be planned, estimated, shipped, and verified. They are also the foundation of every defensible accessibility statement and every credible VPAT.
The nine-step accessibility audit process
The steps below follow the same flow used by accessibility consulting firms, but compressed into a workflow a single developer or product team can execute. Work top-to-bottom — each step builds context for the next.
Define the scope and target standard
Before testing, decide which standard you are auditing against (WCAG 2.2 Level AA is the 2026 default), which pages or templates are in scope, and which user flows must work end-to-end. A typical scope includes the homepage, top 10 landing pages, primary navigation, search, checkout or signup flow, account dashboard, and any forms. Document the browsers, screen readers, and devices you will test on.
Run an automated baseline scan
Use axe DevTools, Lighthouse, or WAVE to scan every in-scope page. Automated tools reliably catch missing alt text, low contrast, missing form labels, missing language attributes, duplicate IDs, and obvious ARIA misuse. Export the results — they form your starting issue list, but understand that automated coverage is only 30–40% of WCAG.
Perform a keyboard-only walkthrough
Unplug your mouse and navigate every in-scope page using Tab, Shift+Tab, Enter, Space, Arrow keys, and Escape. Confirm every interactive element is reachable, focus order is logical, focus indicators are clearly visible, no element traps focus, modals trap and restore focus correctly, and skip links work. Note every failure with the page URL and steps to reproduce.
Test with a screen reader
Run at least one screen reader pass with NVDA (Windows, free), JAWS (Windows), or VoiceOver (macOS/iOS). Listen for whether headings convey page structure, whether images have meaningful alt text or are correctly marked decorative, whether form fields announce their labels and errors, whether dynamic content updates are announced via live regions, and whether ARIA roles and states match the visible behavior.
Check color, contrast, and zoom
Verify that body text meets WCAG 1.4.3 contrast ratios (4.5:1 for normal text, 3:1 for large text and UI components), that information is never conveyed by color alone, that text can be resized to 200% without loss of content or functionality, and that the layout reflows cleanly at 320px width and 400% zoom per WCAG 1.4.10.
Review forms, errors, and time limits
Every input must have a programmatically associated label. Error messages must be announced to assistive technology and clearly identify the field at fault. Required fields must be marked accessibly (not by color alone). Time limits must be adjustable, extendable, or removable per WCAG 2.2.1. CAPTCHAs must have an accessible alternative.
Inspect dynamic widgets and ARIA
For every custom widget — modals, tabs, accordions, comboboxes, date pickers, carousels — verify it follows the WAI-ARIA Authoring Practices pattern: correct roles, correct states (aria-expanded, aria-selected, aria-current), keyboard interaction model (arrow keys for composite widgets), and focus management. Most real WCAG failures live in custom widgets.
Document findings with severity and WCAG mapping
For each issue, record: the page or component, the WCAG success criterion failed (e.g., 1.3.1, 2.4.7), the WCAG technique that would fix it (e.g., H44, ARIA14), severity (critical / high / medium / low), the user impact in plain language, reproduction steps, and a recommended code-level fix. This is the deliverable that turns an audit into a remediation plan.
Triage, remediate, and re-test
Sort findings by severity and frequency. Critical issues (blocking access for entire user groups) ship first. After each fix, re-run the original failing test — not just the automated scan — to confirm the issue is genuinely resolved and no regression has been introduced elsewhere. Add a regression test to CI so the same failure cannot return.
Tools you will need
You do not need a paid platform to run a competent audit. The tools below cover every step in the process.
- Automated scanner: axe DevTools (browser extension) or Lighthouse (built into Chrome DevTools) for the baseline scan.
- Screen reader: NVDA on Windows is free and is the most widely used screen reader worldwide. On macOS, VoiceOver is built in. Pair the screen reader with the browser most of its users prefer (NVDA with Firefox or Chrome, VoiceOver with Safari).
- Contrast checker: our contrast checker for spot-checks, or the contrast panel inside Chrome DevTools.
- Heading and structure inspector: our heading analyzer for verifying logical heading hierarchy.
- AI remediation assistant: the AI Audit Helper to turn raw findings into severity-tagged, WCAG-mapped issues with code-level fixes.
The ten most common issues we find
If you only have time to check ten things, start with these — they account for the majority of real WCAG 2.2 AA failures we see in production audits.
- Missing or meaningless alternative text on informative images (WCAG 1.1.1)
- Color contrast below 4.5:1 for body text or 3:1 for UI components (WCAG 1.4.3, 1.4.11)
- Custom controls built with
<div>or<span>instead of native buttons and links (WCAG 2.1.1, 4.1.2) - Missing or incorrect form labels and error associations (WCAG 1.3.1, 3.3.1, 3.3.2)
- Illogical heading order or skipped levels (WCAG 1.3.1)
- Keyboard traps inside modals, carousels, or embeds (WCAG 2.1.2)
- Focus indicators removed by
outline: nonewithout a visible replacement (WCAG 2.4.7) - Dynamic content changes that are not announced to assistive technology (WCAG 4.1.3)
- Touch targets smaller than 24 by 24 CSS pixels — a new requirement in WCAG 2.2 (WCAG 2.5.8)
- Drag-and-drop interactions with no single-pointer alternative, another WCAG 2.2 addition (WCAG 2.5.7)
How AI fits into a modern accessibility audit
Large language models do not replace expert review, but they dramatically compress the most time-consuming parts of an audit: mapping a symptom to the correct WCAG criterion, writing a plain-language user impact, and drafting a code-level fix that the engineering team can apply. A human still needs to verify behavior with assistive technology, but the AI handles the triage and the writing. Our AI Accessibility Audit Helper is built exactly for this loop — paste a finding in plain English or as a code snippet, and get back a structured analysis you can hand straight to a developer.
What to do after the audit
An audit report on a shelf does nothing. The output should feed three downstream artifacts: a prioritized remediation backlog (a Jira or Linear project), an updated accessibility statement that honestly reflects the site's current conformance, and a CI configuration that prevents the highest-frequency failures from coming back. Treat the audit as the start of an ongoing practice, not a one-time event — accessibility regressions are the rule, not the exception.
Run your first audit in the next hour
Use the AI Audit Helper to map findings to WCAG criteria and generate code-level fixes, then verify with the URL Auditor, Heading Analyzer, and Contrast Checker.
Frequently asked questions
What is a website accessibility audit?
A website accessibility audit is a structured evaluation of a website against an accessibility standard — most commonly WCAG 2.2 Level AA. It identifies barriers that prevent people with disabilities from perceiving, operating, or understanding the site, and documents each issue with severity, the WCAG criterion it fails, the user impact, and a recommended fix. A complete audit combines automated scanning, manual keyboard and screen reader testing, and code-level review.
How long does an accessibility audit take?
For a single template-driven marketing site of under 20 unique page types, a thorough WCAG 2.2 AA audit typically takes 20–40 hours of expert time. Large applications with authenticated flows, complex forms, dashboards, and dynamic widgets can take 80–200+ hours. Automated tools can scan thousands of pages in minutes but only catch 30–40% of real WCAG issues, so manual review is always required for a defensible audit.
What WCAG version should I audit against in 2026?
Audit against WCAG 2.2 Level AA. WCAG 2.2 was published as a W3C Recommendation in October 2023 and is the version referenced by current U.S. Department of Justice Title II rulemaking, the EU European Accessibility Act, and most procurement requirements as of 2026. WCAG 2.2 is fully backward compatible with 2.1 and 2.0, so meeting 2.2 means you also meet the earlier versions.
Can I audit a website for accessibility using only automated tools?
No. Automated tools like axe-core, Lighthouse, and WAVE catch roughly 30–40% of WCAG failures — primarily missing alt text, color contrast, missing labels, and obvious ARIA misuse. They cannot reliably evaluate whether alt text is meaningful, whether the keyboard tab order is logical, whether focus is managed correctly in dynamic widgets, or whether screen reader announcements make sense. A defensible audit always combines automated scanning with manual keyboard and assistive-technology testing.
What's the difference between an accessibility audit and a VPAT?
An accessibility audit is the testing and analysis activity itself, producing a list of issues to fix. A VPAT (Voluntary Product Accessibility Template) is a standardized vendor document, published as an Accessibility Conformance Report (ACR), that describes how a product conforms to accessibility standards on a criterion-by-criterion basis. You perform an audit, then use the findings to fill out the VPAT. A VPAT without an underlying audit is essentially unsupported.
How often should I re-audit my website?
At minimum, run a full WCAG audit once per year and after any major redesign or platform migration. In addition, integrate automated accessibility scanning into your CI pipeline so every pull request is checked, and spot-check newly built components manually before they ship. High-risk sectors (government, healthcare, financial services, education) often require quarterly audits and re-audits after every release.
What does an accessibility audit report include?
A complete audit report includes: an executive summary with overall conformance status, a per-issue breakdown listing the WCAG criterion failed, severity (critical / high / medium / low), the affected pages or components, a description of the user impact, reproduction steps, screenshots or code snippets, and a recommended remediation. Strong reports also link each issue to the relevant WCAG technique (e.g., H44, ARIA14) and include a prioritized remediation roadmap.
How much does an accessibility audit cost?
Expert-led WCAG 2.2 AA audits typically cost $5,000–$15,000 for a small marketing site, $15,000–$40,000 for a mid-size application, and $50,000+ for large enterprise platforms with authenticated workflows. AI-assisted tooling can dramatically lower this by handling the triage and remediation drafting, leaving accessibility specialists to focus on judgment calls and assistive-technology verification.