Accessibility
Accessibility audit
An accessibility audit is a structured check of a website or app against an accessibility standard, usually WCAG 2.2 Level AA.
Automated scanners find the machine-detectable failures, a person tests the rest with a keyboard and a screen reader, and the report lists each failure with the criterion it breaks, where it occurs and how to fix it.
At a glance
| Also called | Accessibility evaluation, assessment or testing (W3C WAI) |
| Against what | A WCAG conformance level, most often 2.2 Level AA; see WCAG levels |
| Automated layer | Rules a scanner can decide from the DOM, such as missing alt text, unlabeled inputs and low contrast; the axe-core rule list tags each rule with its WCAG level |
| Manual layer | Keyboard operation, screen reader output, focus order, whether alt text and error messages make sense: what a person has to judge |
| Formal method | WCAG-EM: define the scope and target level, explore the site, pick a sample of pages, evaluate it, report |
| The output | Each failure with its criterion, location, severity and fix; often a conformance statement or a VPAT |
| Found by | OverlayQA Accessibility Audit in the extension, and the free accessibility checker for any public URL |
Why it matters
Most of the web fails the first, cheapest layer. The 2026 WebAIM Million found detectable WCAG 2 failures on 95.9% of the top one million home pages, an average of 56.1 errors per page, with low-contrast text on 83.9% of pages and missing alt text on 53.1%. Those are the failures a scanner catches in seconds. WebAIM also notes that not every conformance failure can be detected automatically, which is why an audit pairs the scan with a person.
How do you run an accessibility audit?
- 1. Set the target. Pick the WCAG version and level you will claim, usually 2.2 Level AA, and the browsers and assistive technologies you will test with. WCAG-EM calls this the accessibility support baseline.
- 2. Scan a sample of every page type. The home page, a form, a listing, a detail page, checkout, anything with a modal. Run the automated scanner first and fix what it finds; it is the cheap half.
- 3. Test with a keyboard. Tab through each sampled page: every control reachable, a visible focus indicator, a skip link, no traps, a sensible order.
- 4. Test with a screen reader. Headings, landmarks, image alternatives, form labels and error messages should read as intended, not just exist.
- 5. Check complete processes. Conformance covers whole flows, so a checkout or sign-up is audited end to end; WCAG-EM evaluates every page in a process at the target level (Step 4).
- 6. Report and retest. One row per failure with criterion, location, severity and fix. Retest after the fixes land, and schedule the scan so regressions surface before the next audit.
Automated or manual?
| Check | Who finds it |
|---|---|
| Image with no alt attribute | Scanner |
| Alt text that reads "image123.jpg" | A person: the attribute exists, the meaning is wrong |
| Text at 3:1 on a plain background | Scanner; a person when the text sits on a photo |
| Modal that traps keyboard focus | A person with a keyboard |
| Form error shown only by turning the field red | A person, checking color is not the only cue |
| No skip link | Scanner flags it; a person confirms the link works |
Common mistakes
- Treating a clean scan as conformance. A scanner can only decide a subset of the criteria; a page with zero automated errors can still fail keyboard, screen reader and content checks.
- Auditing only the home page. Forms, tables, modals and checkout are where most manual failures live, and a process conforms only if every step does.
- Skipping the keyboard pass. It takes minutes per page and finds the failures that lock people out entirely: missing focus indicators, traps, unreachable controls.
- Reporting without the criterion. "Button is inaccessible" cannot be fixed or verified; "button has no accessible name, 4.1.2, selector .hero button" can.
- Auditing once. Every deploy can reintroduce a failure. Keep the automated layer running on a schedule and reserve the manual pass for releases.
Frequently asked questions
What is the difference between an accessibility audit and an accessibility scan?
A scan is the automated part: a tool reads the page and reports the failures it can decide from the markup and computed styles, such as missing alt text or low contrast. An audit includes the scan and adds manual testing with a keyboard and a screen reader, judgment about content, and a report against a named WCAG level.
Can an automated tool do a full accessibility audit?
No. Automated tools detect the failures that have a machine-checkable rule. WebAIM, which runs an automated scan of one million home pages every year, states that not every conformance failure can be detected automatically. Keyboard traps, focus order, the meaning of alt text and the clarity of error messages all need a person.
What does an accessibility audit report contain?
The scope and the target level, the browsers and assistive technologies used, and one row per failure with the success criterion it breaks, where it occurs, how severe it is and how to fix it. Formal reports following WCAG-EM can add an evaluation statement naming the date, the WCAG version and the level evaluated.
How often should you audit a website for accessibility?
Run the automated layer continuously or on a schedule, because every deploy can reintroduce a failure, and do a manual pass before major releases and after redesigns. The W3C advises evaluating throughout design and development, since problems found early are far cheaper to fix than problems found after launch.
Sources: W3C WAI, Evaluating Web Accessibility Overview, W3C, WCAG Evaluation Methodology (WCAG-EM) 2.0, WebAIM, The WebAIM Million 2026, Deque Systems, axe-core Rule Descriptions.
Last updated October 22, 2026