What is an accessibility audit?

A structured check of a website or app against a standard, almost always WCAG 2.1 or 2.2 level AA, that records every failure with where it is, which success criterion it breaks, how badly it affects people, and how to fix it.

Can an automated tool do a full accessibility audit?

No. Automated checkers reliably find machine-detectable issues like missing alt attributes, missing form labels and low contrast, but a large share of WCAG — keyboard traps, meaningful alt text, focus order, screen-reader announcements — needs a person.

How many pages should an accessibility audit cover?

W3C's evaluation methodology (WCAG-EM) recommends a representative sample: every distinct template and every key user journey, such as sign-up and checkout, plus a few randomly chosen pages. That is often 10 to 30 pages even for a large site.

What should an accessibility audit report contain?

Scope and standard, the method and tools, a summary, and a row per issue with location, success criterion, level, severity, a description of the impact, and a recommended fix. Many buyers then need the results in an Accessibility Conformance Report (a filled VPAT).

How to do an accessibility audit

An accessibility audit checks a site against WCAG — almost always 2.1 or 2.2 at level AA — and writes down every failure clearly enough that a developer can fix it and a buyer can trust it. Here is the method auditors use, the free tools, and the report structure.

On this page

Step 1: define scope and pick the pages
Step 2: run automated scans
Step 3: the manual checks tools miss
Step 4: rate severity
Step 5: write the report
After the audit

Step 1: define scope and pick the pages

Write down the standard (for example WCAG 2.2 level AA), the site or app version, the date, and the browsers and assistive technology you will test with. Then choose a sample, following W3C's WCAG-EM methodology:

One page of every distinct template — home, listing, article, product, form, search results, account.
Every step of each key journey — sign-up, log-in, checkout, contact. A failure in the middle of a journey blocks everything after it.
A few randomly chosen pages as a check on the sample.

Step 2: run automated scans

Automated tools are fast and consistent, and catch the mechanical failures: missing alt attributes, unlabeled inputs, empty links and buttons, duplicate IDs, missing page language, low text contrast. Free options:

Lighthouse (built into Chrome DevTools) — a quick score and a list, using the axe-core rules.
axe DevTools and WAVE — browser extensions that annotate the page.
For contrast specifically, a dedicated checker that handles transparency and gradients — see the WCAG contrast rules.

Treat a clean automated scan as the start. Many WCAG criteria cannot be judged by software at all: whether alt text is meaningful, whether focus order makes sense, whether an error message is announced.

Step 3: the manual checks tools miss

Keyboard only

Unplug the mouse. Tab through every page: can you reach and operate every link, button, menu and form control? Is the focus indicator always visible (2.4.7)? Does focus ever get trapped in a widget (2.1.2)? Does the order make sense (2.4.3)?

Screen reader

Use NVDA (free, Windows) or VoiceOver (built into macOS and iOS). Listen to headings, landmarks, link text, form labels, and what happens when you submit a form with errors. Custom widgets — dropdowns, tabs, modals — are where most problems hide.

Zoom and reflow

Zoom to 200% (1.4.4), then narrow the window to 320 CSS pixels wide (1.4.10). Nothing should be cut off or require scrolling in two directions to read.

Content

Headings form a sensible outline (1.3.1). Images have alt text that says what they mean, and decorative ones have empty alt (1.1.1). Colour is never the only way information is shown (1.4.1). Video has captions (1.2.2).

Contrast in every state

Check hover, focus, visited, error and placeholder states, text over images and gradients, and input borders and icons against the 3:1 non-text rule (1.4.11).

Step 4: rate severity

Severity	Meaning	Example
Critical	Blocks a task completely for some users	Checkout button unreachable by keyboard
Serious	Task possible but very hard	Form errors not announced to screen readers
Moderate	Causes friction or confusion	Body text at 3.9:1 contrast
Minor	Annoyance, workaround obvious	Redundant title attribute on a link

Step 5: write the report

A report a client can act on has:

Scope: standard and level, pages tested, dates, tools and assistive technology.
Executive summary: how many issues at each severity, and the biggest risks, in plain language.
One row per issue: page and element, WCAG success criterion and level, severity, what happens to a real user, and a concrete fix — "change #9ca3af to #6b7280", not "improve contrast".
Evidence: a screenshot or the code snippet for each.

Organisations selling software to governments, universities or large companies are usually asked for the results in a standard format: an Accessibility Conformance Report (a filled VPAT).

ContrastForge covers the contrast part of an audit: it scans every visible text element and form control on a page, maps each failure to 1.4.3, 1.4.6 or 1.4.11, suggests the nearest passing colour, and exports the list as a report with your logo. It does not claim to test the rest of WCAG — pair it with keyboard and screen-reader testing.

See ContrastForge

After the audit

Fix critical and serious issues first, then re-test those exact items and record the date. Add automated checks to your build so the mechanical failures don't come back, and repeat the manual pass whenever templates or key journeys change.

More on this topic: Colour contrast checker · Color blindness simulator · Accessible color palette generator · WCAG 2.2 AA checklist: all 55 success criteria in plain language