WCAG Audit: How to Run One (Step by Step)

A WCAG audit is a structured review of your site against the WCAG 2.2 success criteria — the technical rules that define what 'accessible' means in practice. It splits into two halves: automated checks that catch objective failures in seconds (contrast, alt text, missing labels), and manual checks that require a human moving through the page the way a real user would (keyboard navigation, screen reader behavior, zoom).

The reason both halves matter: automated tools catch roughly 30–40% of all WCAG issues. They're excellent at finding the measurable stuff, but they can't judge whether a heading hierarchy makes sense, whether a focus order is logical, or whether an error message actually helps. A complete audit always includes both passes.

WCAG defines three conformance levels:

• Level A: the minimum. Covers the most critical barriers — missing alt text, no keyboard access, no captions on video. Failing Level A means a chunk of users literally cannot use your site.
• Level AA: the standard most legal and procurement requirements reference. Adds contrast requirements, resize text, consistent navigation, and error identification. This is the level you should target.
• Level AAA: the aspirational ceiling. Nice to have, but few sites achieve full AAA and it's not required for most compliance contexts.

Start with the tools. They're fast, free, and catch the high-frequency failures that make up the majority of real-world accessibility problems.

Use axe DevTools (browser extension), Lighthouse (built into Chrome), or WAVE. Run each on your most important pages — homepage, pricing, signup, and any page with forms. Record every issue: the element, the WCAG criterion it fails, and the page.

Put your mouse aside. Tab through every page and ask: can I reach every interactive element? Is the order logical? Is there a visible focus ring? Can I activate buttons and links with Enter or Space? Can I escape a modal?

This catches what no automated tool can — keyboard traps, illogical tab order, and mouse-only interactions. It's the single most important manual check.

Turn on VoiceOver (Mac), NVDA (Windows), or TalkBack (Android) and listen to your homepage and one form flow. Ask: are headings announced as headings? Does alt text describe images meaningfully? Can I navigate by landmarks? Do form fields announce their labels?

You don't need to be a screen reader expert — just listening for 10 minutes will surface the issues that matter most.

Zoom to 200% and check: does the layout reflow without horizontal scrolling? Is text still readable? Do elements overlap?

Then test color contrast with a tool like the WebAIM Contrast Checker. Body text needs at least 4.5:1 against its background; large text needs 3:1. Low contrast is the single most common automated accessibility failure across the web.

Group your findings into three buckets:

• Critical: keyboard traps, missing form labels, no alt text on meaningful images. These block core use for real people — fix this week.
• High: low contrast, missing focus states, broken heading order. These affect most users — fix this month.
• Medium/Low: redundant ARIA, minor zoom issues, missing captions on optional video. Fix when you can.

Accessibility isn't a one-time project — it decays every time new code ships without it. Add automated checks to your CI pipeline, run a keyboard pass on every release, and make accessibility a review criterion for new features. An audit is a snapshot; an accessible culture is the product.

The automated half of a WCAG audit — contrast, alt text, labels — is part of what a free scored audit covers, so you can see where you stand before the manual pass. For the full checklist, see our WCAG 2.2 AA checklist, and for the legal context, read our ADA website compliance guide.