Accessibility audit checklist: what a WCAG 2.2 AA audit checks, criterion by criterion

"Accessibility audit checklist" is searched about 720 times a month in the United States, and most of the pages that rank for it list ten or eleven things to look at: alt text, contrast, the keyboard, headings, forms. Those are the right things to look at. They are not an audit. A WCAG 2.2 Level AA audit is 55 success criteria, five conformance requirements that most checklists never mention, and a sampling method, and the part that takes judgement is knowing which of the 55 a tool can settle and which need a person.

This checklist covers all of it: the W3C's own audit method, revised in July 2026; every Level A and AA criterion with how it is actually tested; and a count, from the rule metadata itself, of how many of the 55 the most widely used rule engine can see at all.

What an audit is, and three things that are not

An accessibility audit evaluates a defined set of pages or screens against a stated conformance target and reports, criterion by criterion, whether each is met, with the instances that fail and where. The target is almost always WCAG 2.2 Level AA. WCAG 2.2 has 86 success criteria, 31 at Level A, 24 at AA and 31 at AAA (counted from the Recommendation as updated on December 12, 2024), and Level AA conformance means all 55 A and AA criteria are met. WCAG itself advises against requiring Level AAA as a policy for whole sites, because some content cannot meet every AAA criterion.

Testing to 2.2 also covers the older versions that rules still cite. The DOJ's ADA Title II web rule and EN 301 549 use WCAG 2.1 Level AA, and the Section 508 Standards use 2.0; every A and AA criterion in those versions is among the 55, except 4.1.1 Parsing, which 2.2 removed. Our Section 508 explainer covers how to answer the 4.1.1 row when a 2.0 or 2.1 report still asks for it.

Three things are often called an audit and are not one:

The method: WCAG-EM 2.0 in five steps

The W3C's Accessibility Guidelines Working Group published the WCAG Evaluation Methodology 2.0 as a Group Note on July 23, 2026. It builds on WCAG-EM 1.0 of 2014 and extends it from websites to apps and other digital products. It is guidance, not a standard, but it is the procedure the people who write WCAG recommend, and an audit that departs from it should be able to say why.

Three details in it are worth knowing.

The random sample is a test of the auditor. WCAG-EM sizes it at 10% of the structured sample (its worked example: 80 structured samples and 8 random ones) and Step 4.3 compares the two. If the random pages turn up content types or failures the structured pages did not, that is "an indication that the structured sample set was not sufficiently representative", and the auditor goes back to Step 3 and adds samples until it is.

There is no official score. "WCAG 2 does not provide a rating scheme," the Note says. An aggregated score is optional and, if given, its method has to be documented. A percentage on an audit report is the auditor's own construction.

The whole product beats a sample. "If feasible, it is recommended to evaluate the entire digital product." Sampling exists because full evaluation usually is not feasible by hand. Where a step can be automated, there is no reason to sample it.

The five conformance requirements most checklists skip

The 55 criteria are not all of WCAG conformance. Section 5.2 of WCAG 2.2 adds five requirements, and three of them change how an audit has to be run.

1. Conformance level. Every Level A and AA criterion is met, or a conforming alternate version is provided.
2. Full pages. Conformance "cannot be achieved if part of a web page is excluded." Note 3 to this requirement is the one that matters in 2026: "A full page includes each variation of the page that is automatically presented by the page for various screen sizes." The phone layout is part of the page, so an audit tests at desktop and phone widths, and a hamburger menu that only exists below 768 pixels is in scope.
3. Complete processes. When a page is one step in a process, every page in the process has to conform: "Conformance is not possible at a particular level if any page in the process does not conform at that level or better." WCAG's own example is an online store, where every page from product selection to checkout has to conform for any of them to. One inaccessible payment step fails the product page that starts the process.
4. Only accessibility-supported ways of using technologies. A technique only counts if it works with the assistive technologies users have. This is why Step 1 of WCAG-EM asks for a support baseline.
5. Non-interference. Four criteria apply to all content on the page, including content not relied on for conformance, "because failure to meet them could interfere with any use of the page": 1.4.2 Audio Control, 2.1.2 No Keyboard Trap, 2.3.1 Three Flashes or Below Threshold, and 2.2.2 Pause, Stop, Hide. A third-party chat widget that traps keyboard focus, or an autoplaying video ad, fails the page even when everything else on it is excluded.

For content the site owner does not control, such as user comments or a third-party embed, WCAG allows a statement of partial conformance in a set form: "This page does not conform, but would conform to WCAG 2.2 at level X if the following parts from uncontrolled sources were removed." It also allows a conformance determination for pages with contributed content if non-conforming contributions are repaired or removed within two business days. An audit report should say which of these applies.

How much a tool can check: three numbers that are all true

Automated coverage gets quoted as 20%, 30%, 40% or 57%, and the figures seem to contradict each other. They measure different things.

By criterion: 21 of 55. We read the WCAG tags on all 105 rules in axe-core 4.14.0, released October 5, 2026. axe-core is the open-source engine behind Google Lighthouse's accessibility checks and many commercial scanners. Its rules map to 21 of the 55 Level A and AA criteria. One more criterion, 1.3.4 Orientation, has only an experimental rule, which does not run unless asked for. The other 33 have no rule at all. Of the 21, one rule (target size, for 2.5.8) is switched off by default and runs only when WCAG 2.2 tags are requested. Version 4.14.0 is also the release that made the Label in Name rule for 2.5.3 a standard rule; in 4.13.0 it was experimental.

By planted barrier: 13% to 40%. The UK Government Digital Service built a page with 142 deliberate barriers and ran 13 automated tools over it. The best found 40% and the worst 13%; axe found 29%, or 30% counting the issues it flagged for human review. The results were last updated on April 13, 2018, so treat the exact figures as dated; the size of the gap is the point.

By issue count: 57%. Deque, which makes axe, analysed more than 2,000 of its audits covering over 13,000 pages and nearly 300,000 issues, and found that its automated tests caught 57% of the issues by volume. That is Deque's own figure, measured with its own tools.

All three are consistent, because the problems machines can see are also the most common ones. The 2026 WebAIM Million, an automated scan of the top million home pages, found detectable WCAG failures on 95.9% of them, an average of 56.1 errors a page, and 96% of all detected errors in six categories:

Every one of those six is something a rule engine detects. So automation finds most of the instances of a few very common problems, and nothing at all about most of the criteria. A clean scan tells you about 21 criteria, and even for those it tells you only that no rule failed.

A clean rule is not a pass. The rules check what code can check. axe's skip-navigation rule (2.4.1) passes any page that has a heading, a landmark or an internal link. Its title rule (2.4.2) passes any non-empty title, so "Home" on every page passes. Its autocomplete rule (1.3.5) only checks fields that already have an autocomplete attribute; a checkout with none is never reported. Its caption rule (1.2.2) looks for a caption track on a native video element and cannot see inside a YouTube or Vimeo player, which is a cross-origin frame. Its image rule (1.1.1) passes alt="image".

The checklist: all 55 Level A and AA criteria

Each criterion below is marked with how it is tested in practice:

• Rule + review: axe-core 4.14.0 has at least one rule for it. A rule failure is evidence of a failure; a clean result still needs a person to confirm the pass.
• Tool-assisted: no rule decides it, but a measurement or script gathers the evidence (a keyboard focus walk, a 320-pixel viewport, a colour picker, a flash analyser) and a person reads it.
• Manual: a person has to operate, read, watch or listen.

The rule column comes from axe-core's metadata; the line between tool-assisted and manual is our own judgement from how we test, and other auditors draw it slightly differently. The totals: 21 rule plus review, 11 tool-assisted, 23 manual. Criteria new in WCAG 2.2 are marked (new).

Perceivable: 20 criteria

Operable: 20 criteria

Understandable: 13 criteria

Robust: 2 criteria

The new 2.2 criteria are where automation is weakest

WCAG 2.2 added nine criteria, six of them at Level A or AA: 2.4.11, 2.5.7, 2.5.8, 3.2.6, 3.3.7 and 3.3.8. Only one of the six, 2.5.8 Target Size, has an axe-core rule, and that rule is switched off unless the run asks for WCAG 2.2 tags. A team that wires a default axe.run() into its build and calls the result WCAG 2.2 testing has tested none of the six. Ask for the tags explicitly (wcag22a and wcag22aa, alongside the 2.0 and 2.1 tags), and budget manual time for the other five: the sticky header check, the drag alternatives, the help placement, the repeated fields in a process, and the sign-in flow.

What a page scan cannot see at all

Even before judgement comes in, a scan that loads a page and reads it misses whole categories of content:

• States. Hover and focus styles, open menus, expanded accordions, dialogs, error messages and toasts exist only after someone interacts. Contrast, focus visibility and status messages fail most often in exactly those states.
• Cross-origin frames. Video players, maps, chat widgets and hosted payment fields sit in iframes from other domains, and the scanner cannot read inside them. The audit inventories them and tests them by hand, because 2.1.2 and 2.2.2 apply to them regardless.
• Anything behind a sign-in. Account pages, dashboards and checkouts need a test account, and they are often where the complete processes are.
• Documents. PDFs and office files linked from the pages are content in their own right, with their own tags, reading order and language.
• Meaning. Whether an alternative describes its image, a caption matches its speech, a heading describes its section or a link makes sense in context.
• Assistive technology itself. What a screen reader actually announces, and whether voice control can operate the page, depends on the combinations in the support baseline.

The audit checklist, in working order

1. Write the scope. The product and its sections, the target (WCAG 2.2 Level AA), the browsers and assistive technologies in the support baseline, and anything extra the commissioner wants.
2. Inventory the product. Every template, every key task, every process, every embedded third-party component, every document type, and each layout the site switches to on smaller screens.
3. Build the sample. The structured sample covering all of that, a random 10% on top, and every page of every complete process.
4. Run rule engines on every sample page. Two engines are better than one, at desktop and phone widths, signed in where needed, with "needs review" results kept separate from failures.
5. Do the keyboard pass on each template. Tab and Shift+Tab through everything, operate every control, open and close every dialog and menu, and note focus order, visibility, traps and anything hidden under sticky content.
6. Do the visual pass. Zoom to 200%, reflow at 320 pixels, apply the text-spacing values, measure non-text contrast and the contrast of every interactive state.
7. Do the content pass. Alternatives, link text, headings, labels, instructions, error messages, language changes, images of text.
8. Do the media pass. Captions, transcripts, audio description, autoplay, flashing.
9. Work through every form and process. Submit wrong values, let a timeout run, look for repeated questions, sign in with a password manager, confirm what is announced.
10. Check with assistive technology on the baseline combinations, at least through the main processes.
11. Compare the random and structured samples, and widen the sample if the random pages found something new.
12. Report every criterion with a result, the instances, the pages, the date, the tools, and an explicit list of what was not tested.

Where a findings report fits

Rule engines, focus walks and viewport measurements are the parts of this list a pipeline can run at scale, the same way every time, which is why we built ours around them. Our WCAG findings report tests up to 25 pages in a real browser, all of them at desktop width and the first ten at phone width. Conformance Desk's analysis system runs two rule engines and its own probes on every page (a keyboard focus walk of up to 120 stops, reflow at 320 pixels, target size, media, live regions, forms and frames), assigns a conformance level and remarks to all 55 criteria, and lists for the reviewer every criterion it could not settle from the evidence. An accessibility analyst reviews the report before release. It costs $349, comes with a prioritised remediation plan, and is delivered in three business days.

What it does not do is step 10, or the parts of steps 5 to 9 that need a person to operate a component or judge meaning, and every report says so in its method section: manual assistive-technology testing is not part of the method, and neither is judging the accuracy of alternatives or the consistency of navigation across a whole site. Our methodology page lists exactly what is and is not tested, and a complete findings report run against the W3C's demonstration site is on the samples page. If you want a first look before deciding, the free scan tests ten pages with both engines and emails the counts in about fifteen minutes.

Whoever does your audit, the question to put to the report is the one this checklist answers: for each of the 55 criteria, what was tested, how, and on which pages? A report that answers that is an audit. One that cannot is a scan.