WCAG 2.2 Level AA, for people who run shops

Most explanations of WCAG start with the four principles and lose the reader by the second one. This one starts somewhere more useful: with what you are actually being asked to do, how much of it software can check, and which parts of a shop reliably fail.

By the end you should be able to say, out loud and accurately, what “WCAG 2.2 AA” commits your store to, why a clean automated scan is not the same as conformance, and which five or six criteria are worth your attention first.

What conformance actually means

WCAG is organised as four principles, thirteen guidelines and — in version 2.2 — eighty-six testable success criteria across three levels. The levels are not a maturity model you climb at leisure; they are thresholds.

• Level A is the floor. Failing it usually means someone cannot use the page at all.
• Level AA is what law, procurement and litigation almost universally mean when they say “accessible”. It includes every Level A criterion.
• Level AAA is not expected of an entire site, and W3C says so explicitly.

If you are asked for Level AA, you are being asked for all thirty-one Level A criteria and all twenty-four Level AA criteria — fifty-five in total.

Four further formal conformance requirements sit on top of that list, and they are where stores come unstuck far more often than any individual criterion.

Complete pages. Conformance is claimed for a whole page, not the parts you tested. You cannot exclude the cookie banner, the chat widget or the third-party review block because someone else built them. If it renders on your page, it is your page.

Complete processes. If a task spans several pages — and buying something always does — then every page in that process must conform for any of them to be claimed as conformant. A perfect product page and a broken checkout do not average out. This single requirement is why we build the scanner to reach a populated basket and a hydrated checkout rather than stopping at the home page.

Accessibility-supported ways of using technologies. You only get to rely on a technique if it actually works in the assistive technology your visitors have. A clever ARIA pattern that only behaves in one screen reader is not a solution.

Non-interference. Content that fails a criterion must not interfere with the rest of the page. An inaccessible carousel that traps keyboard focus does not just fail its own criteria; it takes the page down with it.

What changed in WCAG 2.2

WCAG 2.2 added nine success criteria and removed one. Six of the additions are at Level A or AA, so they are the only part of the delta that changes what conformance means for you.

The other three additions are Level AAA: 2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance and 3.3.9 Accessible Authentication (Enhanced). Note that 2.4.13 Focus Appearance was numbered 2.4.11 in earlier WCAG 2.2 drafts — and demoted from AA to AAA on the way to publication — a reliable source of confusion in older articles.

4.1.1 Parsing was removed entirely as obsolete. Browsers now recover from the markup problems it described, and where bad markup genuinely breaks something, another criterion catches it. Valid HTML is still worth having. It is no longer a conformance requirement of its own, and any tool still reporting 4.1.1 failures against WCAG 2.2 is reporting against a version that no longer exists.

Two of these additions are unusually relevant to shops, and both are new obligations rather than clarifications.

3.3.7 Redundant Entry lands squarely on checkout. If a customer types their delivery address at step one, you may not make them retype it at step three; it must be pre-filled or selectable. Guest checkouts that ask for an email address twice, and multi-step forms that lose what was entered on a validation error, now fail a Level A criterion.

3.3.8 Accessible Authentication lands on account login. A CAPTCHA that requires transcribing distorted text is a cognitive function test. Object recognition and identifying non-text content the user provided are among the listed exceptions, and a password manager must not be blocked — so autocomplete="off" on a password field, or scripting that defeats paste, is now a conformance problem rather than merely a rude one.

Where a shop actually fails

Across the WooCommerce and WordPress stores we scan, failures cluster in about six places. In rough order of how often they appear and how much they cost:

1.4.3 Contrast (Minimum), AA. Body text at 4.5:1, large text at 3:1. Sale badges, “only 2 left” notices, placeholder text, disabled-looking buttons that are not disabled, and white text over a photographic hero are the recurring offenders. Contrast is arithmetic, so this is one of the few criteria a machine judges as well as a person — but the fix is a brand decision, which is why our own contrast fix always waits for a human to approve it. How we handle contrast.

4.1.2 Name, Role, Value, A. The criterion behind every nameless icon button: the search magnifier, the cart toggle, the quantity steppers, the gallery arrows. To a screen reader they announce as “button” and nothing else; to voice control they have no name to say. How we handle unnamed buttons.

1.1.1 Non-text Content, A. Product images with no alternative text, or with the filename as alternative text, which is worse. This is the highest-volume failure in most catalogues simply because there are so many images. How we handle alt text.

2.4.4 Link Purpose (In Context), A. “Read more” fourteen times on a category page. Screen reader users navigate by pulling up a list of links, and an identical list is useless. This one is genuinely context-dependent, which is why it is one of the three fixes we never apply automatically. How we handle ambiguous links.

3.3.2 Labels or Instructions, A, and 1.3.5 Identify Input Purpose, AA. Checkout fields with placeholder text instead of labels, and fields with no autocomplete token so autofill cannot help. The second one is the criterion nobody knows about and everybody fails. How we handle form labels · how we handle autocomplete.

2.4.1 Bypass Blocks, A. No skip link, so a keyboard user tabs through the entire header — promo bar, logo, search, mega-menu — on every single page, including checkout. How we handle skip links.

2.5.8 Target Size (Minimum), AA — new in 2.2, and mobile-first themes fail it constantly. Colour swatches, star ratings used as filters, quantity steppers and pagination numbers are frequently under 24 by 24 pixels. Note the exceptions before you panic: targets inside a sentence are exempt, as are targets whose size is determined by the user agent or is essential to the information conveyed.

How much of this can be tested by a machine

This is the part most tooling pages skip, so here are our own numbers, generated from the same tables that drive our scanner.

Of the fifty-five WCAG 2.2 Level A and AA success criteria, thirty-nine have at least one automated rule or probe behind them in our engine — three independent engines plus nine custom measurement probes. Sixteen have none at all.

Those sixteen are not an oversight and they are not a gap we intend to close with cleverness. They are criteria that require a judgement:

• Whether an error message actually helps someone correct their mistake (3.3.3 Error Suggestion).
• Whether the reading order makes sense to someone who cannot see the layout (2.4.3 Focus Order).
• Whether an image of text was necessary (1.4.5 Images of Text).
• Whether a multipoint or path-based gesture has a workable single-pointer alternative (2.5.1 Pointer Gestures).
• Whether the same function is labelled consistently across the site (3.2.4 Consistent Identification).
• Whether a form that commits money offers review, confirmation or reversal (3.3.4 Error Prevention).

A machine can tell you that a form exists. It cannot tell you whether cancelling an order is reversible.

And even for the thirty-nine that are covered, coverage means “we can find some failures”, never “we can confirm this criterion is met”. Automated testing catches a minority of the barriers on a typical page. The honest statement of what a clean scan means is: no machine-detectable violation was found. That is worth having. It is not conformance, and any tool that tells you otherwise is selling you something.

A sequence that actually works

If you are starting from nothing, do it in this order. It front-loads the failures that lock people out and defers the ones that merely annoy.

Week one — measure, then fix the checkout. Scan the store, then ignore most of the report and go straight to the basket and checkout findings. Unlabelled fields, missing autocomplete tokens, error messages that are not announced, focus that does not move to the error, and a “Place order” button with no accessible name. This is where inaccessibility costs you money rather than goodwill. Our own accessible checkout guide is the long version.

Week two — the global furniture. A skip link, a sane landmark structure, one h1 per page, a visible focus indicator that you have not removed in a stylesheet, and contrast on the header, footer and notice components. These are template-level fixes: you do each one once and every page benefits.

Week three — the catalogue. Alternative text, in a real pass rather than a bulk-fill. Product photos describe the product; lifestyle shots describe what matters about the scene; decorative flourishes take an empty alt; an image of a size chart needs the chart’s content available as text. See alt text done properly.

Week four — keyboard and screen reader, by hand. Unplug the mouse and buy something. Then do it again with VoiceOver or NVDA running. You will find things no scanner reports, and you will find them in about twenty minutes. This is also when you discover whether your mega-menu is operable, which no automated rule will tell you.

Then — the sixteen. Whatever remains is judgement work: reading order, error suggestions, consistent identification, error prevention on the order form. Either you have someone who can assess those against the criteria, or you buy a human audit, which is the only thing that ends in a conformance statement someone else will accept.

Writing it down honestly

Two documents matter once the work is underway, and both are easy to get wrong in the same direction.

An accessibility statement describes your scope, the standard you are working to, the date, what you know is still broken, and how to tell you about a problem. A statement claiming full conformance while your checkout fails Level A is worse than no statement: it is a written record that you were told and did not act. How to write one properly.

A conformance report — a VPAT or ACR — is the document procurement teams ask for by name, criterion by criterion, with support levels and remarks. It is produced by an audit, it names a scope and a date, and it expires in practice the moment the store changes materially. If you sell into the public sector or to large buyers, you will be asked for one.

The distinction between those two is the same distinction that runs through everything above. Software finds failures and can fix a defined set of them, in your real HTML, provably. A qualified human establishes conformance. Anyone collapsing those two things into one claim is either confused or hoping you are.

An automated finding is evidence, not a certificate. Conformance is certified only by the professional audit — scoped, dated and signed by qualified humans. Every other sentence on this site is written to be checkable, and so is that one.