WCAG 2.2 audit checklist: what an accessibility audit should cover

An accessibility audit checks your website or web app against the Web Content Accessibility Guidelines, and tells you what stops disabled people from using it and how to fix it. This checklist covers what a WCAG 2.2 AA audit should include, from scoping to the re-test.

Automated tools are a good start, but they find only a fraction of real barriers, roughly a third in our experience. They can tell you an image has no alt text; they can’t tell you the alt text is useless, that focus jumps somewhere unexpected, or that a form is impossible to complete with a screen reader. That takes a person, using the product the way disabled people do.

Before you start: scope the audit

A good audit is scoped around what people actually do, not a random sample of pages.

• The key journeys. Sign-up, sign-in, the core task, checkout or booking, account settings. If someone can’t complete these, nothing else matters.
• The templates. Most sites are built from a handful of page types. Audit each once, properly.
• The components. Menus, modals, forms, date pickers, carousels, tabs and tables are where most barriers live.
• The standard. WCAG 2.2 at level AA is the current benchmark. In the EU, EN 301 549 is built on WCAG 2.1 AA, and 2.2 includes all of it. In the US, the ADA and Section 508 are tested against WCAG too.
• The assistive technology. At minimum, NVDA with Chrome or Firefox on Windows, VoiceOver on macOS and iOS, and TalkBack on Android, plus keyboard-only use, zoom and high contrast.

The checklist

WCAG is organised under four principles: content must be perceivable, operable, understandable and robust. These are the level A and AA success criteria we find matter most in practice, with their numbers so you can look each one up.

Perceivable

• Text alternatives (1.1.1). Every meaningful image has alt text that says what it shows or does. Decorative images have an empty alt.
• Captions (1.2.2). Pre-recorded video with sound has accurate captions.
• Info and relationships (1.3.1). Headings, lists, tables and form labels are marked up as what they are, not just styled to look like them.
• Orientation (1.3.4). The product works in both portrait and landscape.
• Identify input purpose (1.3.5). Fields for name, email, address and the like carry the right autocomplete attributes.
• Contrast (1.4.3). Body text has at least 4.5:1 contrast with its background, and large text at least 3:1.
• Resize text (1.4.4). Text can be enlarged to 200% without losing content or function.
• Reflow (1.4.10). Content works at 320 CSS pixels wide without scrolling in two directions.
• Non-text contrast (1.4.11). Input borders, icons and focus indicators have at least 3:1 contrast.
• Text spacing (1.4.12). Nothing breaks when users increase line, letter and word spacing.
• Content on hover or focus (1.4.13). Tooltips and popovers can be dismissed, hovered and stay visible until the user is done.

Operable

• Keyboard (2.1.1). Everything works with a keyboard alone.
• No keyboard trap (2.1.2). Focus can always move away from any component.
• Timing adjustable (2.2.1). Time limits can be turned off, adjusted or extended.
• Pause, stop, hide (2.2.2). Moving, blinking or auto-updating content can be paused.
• Three flashes (2.3.1). Nothing flashes more than three times a second.
• Bypass blocks (2.4.1). A skip link or landmarks let people jump past repeated navigation.
• Page titled (2.4.2). Every page has a title that says what it is.
• Focus order (2.4.3). Focus moves in an order that makes sense.
• Link purpose (2.4.4). Link text says where it goes, not “click here”.
• Headings and labels (2.4.6). Headings and labels describe their content.
• Focus visible (2.4.7). You can always see where keyboard focus is.
• Focus not obscured (2.4.11). Focused items aren’t hidden behind sticky headers, banners or chat widgets.
• Label in name (2.5.3). A control’s visible label is part of its accessible name, so voice control works.
• Dragging movements (2.5.7). Anything done by dragging can also be done with a single pointer, without dragging.
• Target size (2.5.8). Tap and click targets are at least 24 by 24 CSS pixels, or have enough space around them.

Understandable

• Language of page (3.1.1). The page declares its language, so screen readers pronounce it correctly.
• On focus and on input (3.2.1, 3.2.2). Focusing or changing a field doesn’t trigger unexpected changes of context.
• Consistent navigation and identification (3.2.3, 3.2.4). Navigation and repeated components behave the same everywhere.
• Consistent help (3.2.6). Help, such as contact details or chat, appears in the same place across pages.
• Error identification and suggestion (3.3.1, 3.3.3). Errors are described in text, with a suggestion for fixing them.
• Labels or instructions (3.3.2). Every field has a visible label and any instructions it needs.
• Redundant entry (3.3.7). People aren’t asked to type the same information twice in one process.
• Accessible authentication (3.3.8). Signing in doesn’t depend on a memory or puzzle test, such as transcribing characters, unless there’s an alternative. Allowing password managers and paste goes a long way.

Robust

• Name, role, value (4.1.2). Every custom control exposes what it is, what it’s called and what state it’s in.
• Status messages (4.1.3). Messages such as “added to basket” or form errors are announced without moving focus.

What changed in WCAG 2.2

If your last audit was against WCAG 2.1, these are the new level A and AA criteria to add:

• 2.4.11 Focus not obscured (minimum), AA
• 2.5.7 Dragging movements, AA
• 2.5.8 Target size (minimum), AA
• 3.2.6 Consistent help, A
• 3.3.7 Redundant entry, A
• 3.3.8 Accessible authentication (minimum), AA

WCAG 2.2 also removed 4.1.1 Parsing, which modern browsers and assistive technology made obsolete.

How the findings should be reported

A report is only useful if the people who fix things can act on it. Every finding should include:

• The screen and the element, with a screenshot
• The WCAG success criterion it fails
• Who it stops, for example keyboard users or screen reader users
• A severity, so the team fixes blockers before cosmetic issues
• The fix, specific enough to build

Findings should be ranked by impact, not listed in WCAG order. A checkout that can’t be completed with a keyboard matters more than twenty minor contrast issues, even though it’s one line in the report.

After the audit

• Fix in order of impact. Blockers on key journeys first, then the rest.
• Fix the system, not just the screen. Many issues live in shared components or colour tokens, so one change fixes every page that uses them.
• Re-test. A re-test confirms the fixes work with real assistive technology and catches anything they broke.
• Publish an accessibility statement. Say what standard you meet, what’s still being fixed and how people can report problems. Public sector bodies in the UK and EU are required to.
• Keep it in the process. Accessibility checked in every sprint stays fixed. Accessibility checked once a year keeps coming back.

When to bring in help

You can run much of this checklist yourself. An external audit earns its keep when you need evidence for a buyer, a regulator or a tender, when your product relies on complex custom components, or when you simply want experienced testers who use assistive technology every day.

Our WCAG accessibility audit covers everything above, in about three weeks, with every barrier ranked, a fix plan your engineers can use and a re-test. Every product we ship is built to WCAG AA, and our founder has been doing accessibility work for more than ten years, including for the NHS.