How to Run a Website Accessibility Audit (Step by Step)

"Audit our site for accessibility" sounds daunting, but it's a repeatable process: decide what to test, clear the machine-detectable issues with a scan, do the manual checks a tool can't, prioritise, write it down, and keep it from sliding back. This guide is the practical version — useful whether you're a developer checking your own work or a freelancer auditing a client site. (General information, not legal advice.)

Step 1 — Scope it

You rarely need to test every page. Pick a representative set: your templates (home, a content page, a listing page, an article) plus the key journeys (sign-up, search, cart, checkout, contact). A handful of well-chosen pages covers most of the code that real users touch. Note the target standard up front — almost always WCAG 2.2 Level AA.

Step 2 — Run an automated scan

Start here because it's fast and clears the unambiguous failures (missing alt text, missing labels, low contrast, missing page language). Scan your site free with WCAGwise on each page in scope — it lists issues worst-first and shows the exact element and how to fix it. Automated testing catches a meaningful portion of WCAG criteria, but not all — which is what the next step is for.

Step 3 — Do the manual checks

The judgment calls a tool can't make. For each page:

Keyboard: unplug the mouse and Tab through — can you reach and use everything, in a logical order, with visible focus, no traps? (See keyboard testing.)
Screen reader: navigate with VoiceOver (Mac) or NVDA (Windows) — are headings, links, images, and form fields announced meaningfully?
Zoom & reflow: zoom to 200%+ — does content reflow without horizontal scrolling or overlap?
Forms: trigger an error — is it clear, specific, and announced? (See accessible forms.)
Meaningful alt text & link text: a tool confirms they exist; you confirm they make sense.
Media: captions on video, no auto-playing audio, content not conveyed by color alone.

Step 4 — Prioritise by impact

Sort findings by severity and by how badly they block a real user — not by how easy they are to fix. A checkout you can't complete by keyboard or an unlabeled critical field comes before a minor heading nit. Tackle critical → serious → moderate → minor.

Step 5 — Document it

Record what you tested, what you found (with the WCAG criterion + location), what you fixed, and what's outstanding. This is what turns "we checked" into something you can show a client or regulator. A structured report makes it far easier — see our accessibility statement template, and, for vendors, what a VPAT is.

Step 6 — Re-test and prevent regressions

Accessibility decays as the site changes. Re-scan after every significant release, bake a quick keyboard + scan check into QA, and re-audit periodically. It's a habit, not a one-off project.

Make it faster next time

The automated pass is the part you'll repeat most, so make it one click: Scan your site free with WCAGwise to find issues and their exact locations, then spend your time on the manual checks that matter. WCAGwise is an audit aid, not a legal guarantee — but it removes most of the tedium.

How to run a website accessibility audit (step by step)