WCAG 2.1 vs 2.2: The Changes That Land in Your Checkout

Animated explainer: what changed between WCAG 2.1 and 2.2, the six new A and AA criteria, why four of them live in checkout and login flows, what axe-core 4.14 actually checks, and a manual test plan.

Read the transcript

WCAG 2.1 vs 2.2. The changes that land in your checkout. Most teams treat the move to WCAG 2.2 as a theme update. Bigger buttons. A sticky header that stops covering the focus ring. Re-run the scanner. Done. That misses where the new requirements land. Two are about how the theme looks. Four are about what your checkout and your login ask a person to do. Budget this as a checkout project, and as manual testing. WCAG 2.2 became a W3C Recommendation on 5 October 2023. It added nine success criteria and removed one. Everything else carries over, so a site that meets 2.2 also meets 2.1. Three of the nine are AAA. Two are level A. Four are AA. And 4.1.1 Parsing is gone. If your target is AA, the gap is exactly six criteria. The two everyone knows. 2.4.11 Focus Not Obscured: when something receives keyboard focus, it must not be entirely hidden by content you created. Sticky headers, cookie banners and chat widgets are the usual culprits. 2.5.8 Target Size: pointer targets of at least 24 by 24 CSS pixels — unless there is enough space around them, an equivalent control, or the link sits inside a sentence. Those two get the attention because you can see them. They are also the only two a design review is likely to catch. The other four live in your flows. 3.3.7 Redundant Entry: anything a shopper already typed in the same process must be filled in for them, or offered to select. The textbook case is billing and shipping. A “same as shipping” checkbox meets it. Two details matter. A checkout that hands off to a payment page is still one process. And browser autocomplete alone is not enough — the page has to provide the data itself. 3.3.8 Accessible Authentication: no login step may depend on a memory or puzzle test, unless it offers an alternative or something that helps. A normal password form that a password manager can fill is fine. What breaks it are small security decisions. Blocking paste into the password field fails. A one-time code you have to copy by hand fails. Six little code boxes that reject a pasted code are the common way this goes wrong. 3.2.6 Consistent Help: if you repeat a phone number, a contact link or a chat button across pages, it has to stay in the same relative order. Checkout templates are usually where it moves. 2.5.7 Dragging Movements: anything that works by dragging must also work with a single tap or click. Price sliders, before-and-after images, drag-to-reorder lists. A slider with plus and minus buttons passes. Now the fact that should change your plan. axe-core, the engine under a large share of scanners, publishes its rules. In version 4.14, exactly one rule is tagged for 2.2 AA: target-size. And it is off by default. That is not a criticism of axe. These criteria are about what happens across a sequence of pages. What you typed two steps ago. Whether paste works. Whether the help link moved. A tool looking at one page at a time is not built for that. Do you have to move? The Justice Department’s rule for state and local government sites still names WCAG 2.1 AA, and many agreements do too. I am not an attorney — ask counsel what yours requires. Test to 2.2 anyway: it is backwards compatible, the extra cost is six criteria, and the barriers are real. Walk your real checkout and your real login, and write down what you found against each criterion by number. Manual audits of checkout and account flows run through EcomBack. The full article and the one-page test plan are at ranaahson.com.

Most teams treat the move from WCAG 2.1 to WCAG 2.2 as a theme update. Bigger buttons, a sticky header that stops covering the focus ring, re-run the scanner, done.

That reading misses where the new requirements actually land. WCAG 2.2 added six success criteria at levels A and AA. Two of them are about what the theme looks like. The other four are about what your checkout, account and login flows ask a person to do — and the most widely used automated engine has no rule for any of them.

My position is simple: if you are upgrading from 2.1 to 2.2, budget it as a checkout project, and budget it as manual testing. A clean scan tells you almost nothing about the parts of 2.2 that matter most.

What actually changed between 2.1 and 2.2

WCAG 2.2 became a W3C Recommendation on 5 October 2023. According to the W3C’s own summary, it added nine success criteria and removed one. Everything else from 2.0 and 2.1 carries over essentially unchanged, which is why a site that conforms to 2.2 also conforms to 2.1.

The nine new criteria, by level:

Level A: 3.2.6 Consistent Help, 3.3.7 Redundant Entry
Level AA: 2.4.11 Focus Not Obscured (Minimum), 2.5.7 Dragging Movements, 2.5.8 Target Size (Minimum), 3.3.8 Accessible Authentication (Minimum)
Level AAA: 2.4.12 Focus Not Obscured (Enhanced), 2.4.13 Focus Appearance, 3.3.9 Accessible Authentication (Enhanced)

And one removal: 4.1.1 Parsing is obsolete and is no longer part of WCAG 2.2.

If your target is AA, which is the level US regulations, settlements and procurement documents generally reference, the gap between 2.1 and 2.2 is exactly those six A and AA criteria. That is a small, specific list. It is worth knowing precisely what each one asks for.

The two everyone already knows

2.4.11 Focus Not Obscured (Minimum) says that when a component receives keyboard focus, it must not be entirely hidden by content the author created. Sticky headers, cookie banners and chat widgets are the usual culprits.

2.5.8 Target Size (Minimum) asks for pointer targets of at least 24 by 24 CSS pixels, with exceptions for adequate spacing, an equivalent control elsewhere on the page, links inside a sentence, and controls the browser draws itself.

I covered both, with the theme patterns that fail them, in the Shopify theme audit piece. They get the attention because they are visible. You can see a covered focus ring. You can measure a small icon. They are also the only two of the six that a design review is likely to catch.

The four that live in your checkout

3.3.7 Redundant Entry (Level A)

Information a user has already entered in the same process must be either auto-populated or available to select, rather than typed again. Exceptions cover re-entry that is essential, re-entry required for security, and information that is no longer valid.

The textbook case is billing and shipping. W3C’s Understanding document gives a checkbox that copies the shipping address into the billing fields as a way to meet it. Two details matter for stores:

The W3C guidance treats a process as able to span domains. A checkout that hands off to a third-party payment page is still one process.
Relying on the browser’s autocomplete alone is not treated as sufficient. The page has to provide the data itself.

It does not require you to remember anything between sessions. A returning visitor is starting a new process.

3.3.8 Accessible Authentication (Minimum) (Level AA)

No step of a login may depend on a cognitive function test — remembering a password, solving a puzzle, transcribing a code — unless that step offers an alternative or a mechanism that helps.

This is the criterion I would check first, because it is broken by small decisions developers make for security reasons. According to the W3C’s Understanding document:

A properly marked-up username and password form that a password manager can fill is fine.
Blocking paste into the password field fails, unless another method is available, because it forces the user to transcribe.
A one-time code the user must copy by hand fails. At minimum the user must be able to paste it. Split six-box code inputs that reject a full paste are the common way this breaks.
An object-recognition CAPTCHA (“select the bicycles”) is excepted at AA. A CAPTCHA that requires transcription needs a non-cognitive alternative.

None of that is visible in a screenshot. You find it by logging in.

3.2.6 Consistent Help (Level A)

If you repeat a help mechanism across a set of pages — a phone number, a contact link, a self-help page, a chat bot — it must appear in the same relative order on each of them. It does not require you to offer help at all. It requires that help, once offered, does not move.

On stores this breaks in the checkout, because checkout templates are often built separately from the rest of the site and lose the footer contact block, or put the chat launcher somewhere new.

2.5.7 Dragging Movements (Level AA)

Anything that works by dragging must also work with a single pointer without dragging, unless dragging is essential. On stores, the usual suspects are price-range sliders on collection filters, before-and-after image comparisons, and drag-to-reorder lists in account areas. A slider with plus and minus buttons, or number inputs beside it, passes.

What your scanner checks

Here is the fact that should change how you plan this work. axe-core, the open-source engine underneath a large share of browser extensions and CI scanners, publishes its rule list. In the current rule descriptions (version 4.14), exactly one rule is tagged for WCAG 2.2 AA: target-size, for SC 2.5.8. The documentation also notes that the WCAG 2.2 rules are disabled by default.

There is no rule for 2.4.11, 2.5.7, 3.2.6, 3.3.7 or 3.3.8.

That is not a criticism of axe. These criteria are about behaviour across a sequence of pages — what the user typed two steps ago, whether paste works, whether the help link moved between templates. A rule engine looking at one rendered page at a time is not built to judge them. It does mean that “we ran a scan against WCAG 2.2” can mean the 2.2-specific part of the scan checked one criterion, or none.

Automated testing has always caught only part of WCAG. For the 2.2 additions the gap is wider than usual, and it sits in the flows where your revenue is.

Do you have to move to 2.2?

Not every rule names it yet. The US Department of Justice’s Title II rule for state and local government websites references WCAG 2.1 AA. Many settlement agreements and procurement documents still say 2.1. Other buyers and contracts have started to ask for 2.2. Which standard applies to you depends on who you sell to and where, and I set that out in which accessibility law applies to your store. I am not an attorney; for what a particular agreement or claim requires, consult counsel.

My recommendation is to test to 2.2 AA anyway, for three reasons:

It is backwards compatible. Meeting 2.2 AA also meets 2.1 AA. You are not choosing between them.
The marginal cost is small. Six criteria, most of them checkable in an afternoon by someone who knows what to look for.
The barriers are real. A login that blocks paste locks out people who rely on password managers. A checkout that makes someone type their address twice costs you orders from everyone, and costs the most from people with memory or motor impairments.

A test plan that fits on one page

Walk your real checkout and your real login, on a real device, and record the result against each criterion by number:

3.3.7 — Is any field you already filled asked for again? Is there a “same as shipping” option? Does it survive the hand-off to the payment page?
3.3.8 — Paste a password. Let a password manager fill the form. Paste a full one-time code into the code field. Look at what any CAPTCHA asks for.
3.2.6 — Note where help sits on the home page, a product page, the cart and each checkout step. Is the order the same?
2.5.7 — Use every slider, carousel and reorder control without dragging.
2.4.11 — Tab through each template with the cookie banner and chat widget open. Is anything with focus fully hidden?
2.5.8 — Measure the small controls: quantity steppers, close buttons, swatches, social icons.

Write down what you tested, how, and what you found. If a demand letter ever does arrive, that record is worth more than any badge.

This is the work we do at EcomBack (opens in a new window): manual audits of checkout and account flows against WCAG 2.2 AA, with every finding mapped to a success criterion and a remediation note your developers can act on. It does not remove legal risk — nothing does — but it gives you a documented, defensible position and a checkout more people can complete.

Want a second pair of eyes on your checkout? Book a call with EcomBack (opens in a new window) and we will walk it with you.