How to Run a Website Accessibility Audit

Most accessibility audits fail in one of two directions. Either they never happen, because the standard looks impenetrable and nobody knows where to begin. Or they happen once, produce a 200-page PDF listing four thousand issues, and land on a development team that quietly files it, because there is no plausible route from that document to a fixed website.

A useful audit is smaller, sharper and repeatable. Here is how to run one.

Step 1: Decide what you are auditing against

Pick the standard and level before you start, and write it down. For almost everyone the answer is WCAG 2.2 Level AA — it is the current W3C Recommendation, it is backward compatible with the WCAG 2.1 and 2.0 versions that laws currently name, and it is what UK and Australian government guidance already require.

If a specific regulation applies to you, note which version it names, because it is probably older than 2.2: EU law currently points at WCAG 2.1 AA via EN 301 549 v3.2.1, the US ADA Title II rule names WCAG 2.1 AA, and Section 508 still names WCAG 2.0 AA. Building to 2.2 satisfies all of them.

Step 2: Choose your sample properly

You cannot manually test every page of a site with thousands of pages, and you do not need to. What you need is a sample that covers every distinct template and every critical process.

Include:

• The home page and main landing pages
• One example of every page template — article, product, category, search results, profile, dashboard
• Every step of your critical journeys, end to end: browse, add to cart, checkout, confirmation; registration; login; contact; search
• Any page with a form, a data table, a map, a chart, a video or an embedded third-party widget
• The error states — an empty form submitted, an invalid entry, a failed payment
• Your 404 page and your cookie banner, both of which get skipped and both of which block people

That last category matters more than its size suggests. A cookie consent banner that traps keyboard focus prevents access to the entire site, and it is the first thing every visitor meets.

The reason to test complete processes rather than sampled pages is not thoroughness for its own sake: WCAG conformance is formally claimed for complete processes. If one step of your checkout fails, no page in that checkout can be claimed as conformant.

Step 3: Run automated testing across everything

Automation is where you start, not where you finish, and its value is coverage. Scan every page you can, not just your sample — this is the one part of the audit that scales.

Expect it to find the high-volume mechanical failures: missing alt attributes, form inputs with no accessible name, colour contrast below threshold, empty links and buttons, missing document language, invalid ARIA, incorrect heading nesting, missing table headers. WebAIM's annual analysis of a million home pages finds the same six issue types account for the overwhelming majority of detected errors, so this pass typically clears a large share of your total error count quickly.

Be clear with yourself and your stakeholders about the ceiling. Deque's research found automated tests produced results for 16 of the 50 WCAG 2.1 Level AA success criteria. When the UK's Government Digital Service ran ten automated tools against a page seeded with 143 known barriers, the best single tool found 41%, and 29% were missed by every tool. A clean scan is a real result and not a conformance claim.

Pay particular attention to results the tool marks incomplete rather than pass or fail. These are cases the engine could not decide — most commonly text over an image, gradient or video, where the background colour cannot be read from CSS. Incomplete results are where genuine contrast failures hide, because they are easy to skip.

Step 4: The keyboard pass

Put the mouse away and tab through every page in your sample. This single pass finds more blocking issues than any other manual technique, and it needs no specialist knowledge.

You are looking for: a focus indicator that is always visible; a focus order that follows the visual layout; the ability to reach every interactive element; the ability to escape every modal, menu and widget; a skip link past the navigation; no focusable elements hidden off-screen; and no focused element disappearing behind a sticky header.

That last one is the WCAG 2.2 criterion 2.4.11 and it is very common on modern sites. The UK's public sector monitoring found 2.4.7 Focus Visible to be the single most common failure across the sites it assessed, with 2.1.1 Keyboard third. Our keyboard accessibility guide has the full checklist.

Step 5: The structure and content pass

This is the judgement work, and it is what separates an audit from a scan.

Headings. Check that heading levels describe the actual structure of the page, not the visual size of the text. This matters more than most teams realise: in WebAIM's Screen Reader User Survey #10, published in 2024, 71.6% of respondents said navigating through the headings is the first thing they do when looking for information on a long page. A page whose headings are chosen for typography rather than hierarchy is a page most screen reader users cannot navigate efficiently.

Alt text quality. Automation tells you an attribute exists. Only you can tell whether it says anything useful, whether decorative images are correctly marked empty, and whether images inside links describe the destination rather than the picture. See how to write alt text.

Link and button text. "Click here", "Read more" and "Learn more" repeated fifteen times are meaningless out of context, and screen reader users frequently navigate by pulling up a list of links.

Forms and errors. Every input needs a real label, not a placeholder. Every error needs to be in text, announced, associated with its field and actionable. Test the failure paths deliberately — see accessible forms.

Media. Are captions accurate, or auto-generated and wrong? Does video that conveys information visually have audio description? Is there a transcript?

Reading order and meaning. Does the DOM order match the visual order? Does anything rely on colour alone to convey information? Does content reflow at 400% zoom without horizontal scrolling?

Step 6: Screen reader testing

You do not need to be an expert to get value from this, and thirty minutes of clumsy screen reader use will teach you more than a week of reading.

Use what people actually use. In that same survey, JAWS was the primary desktop screen reader for 40.5% of respondents and NVDA for 37.7%, with Chrome the most common browser pairing. NVDA is free on Windows; VoiceOver ships with macOS and iOS.

Attempt one complete journey with the screen reader on and the screen off or your eyes closed. You will find things no checklist predicts: a button that announces nothing, a modal that leaves you reading the page behind it, a form error you never hear.

The higher-value version of this step is testing with actual disabled users. It is the single most informative accessibility activity most organisations have never done, and a handful of sessions will reorder your priority list.

Step 7: Write findings people can act on

The output of an audit is not a list of violations. It is a plan.

For each finding, record: where it is (page and element), what the problem is in plain language, which success criterion it fails, who it affects and how badly, and how to fix it. A finding pinned to a screenshot is worth several paragraphs of description, because the developer can see exactly what you mean.

Then prioritise on two axes rather than one. Severity — does this block a task completely, or make it harder? And reach — is it on one page, or in a template used on four thousand? A missing label in a global header component is a single fix with enormous reach. A contrast failure in one legal footnote is not.

The order that gets results is: blockers on critical journeys first (things that stop someone completing a purchase or an application), then high-reach template fixes, then the long tail of content issues, which is usually where the raw volume sits and where the impact per fix is lowest.

Step 8: Make it recur

This is the step that determines whether any of it lasts.

Websites change constantly, and accessibility regresses quietly — a theme update removes a focus outline, a new template ships without labels, a marketing page goes live with text over a photograph. The UK's public sector monitoring programme retested 47 websites it had already assessed and notified: only 3 had no issues. Even organisations that had been formally told what was wrong drifted.

So schedule the automated pass to run continuously — weekly or on every deploy — and treat new findings as bugs rather than as a special category of work. Repeat the manual pass on your critical journeys on a fixed cycle, and after any significant redesign. Keep a dated record of what you tested and what you found, both because it makes your accessibility statement truthful and because a documented history of good-faith work is materially more useful than a single audit if anyone ever asks.

An audit is a photograph. Accessibility is the film.

*Coverage figures are from Deque Systems' Automated Accessibility Coverage Report and the UK Government Digital Service's 2017 tool evaluation. Screen reader and heading navigation figures are from the WebAIM Screen Reader User Survey #10, conducted December 2023 to January 2024 with 1,539 responses. Public sector failure rankings and retest figures are from the UK Government Digital Service accessibility monitoring report covering 2022 to 2024.*