The European Accessibility Act came into force on June 28, 2025. Most ecommerce discussion around accessibility has focused on WCAG 2.1 AA — the standard the EAA formally references. But WCAG 2.2, published by the W3C in October 2023, adds nine new success criteria that are more directly relevant to ecommerce than anything in 2.1.
WCAG 2.2 is not yet legally mandated under EAA. The law references the earlier version. But three reasons make it worth your attention regardless:
First, EN 301 549 — the European technical standard that the EAA uses to define compliance — tracks W3C updates. The current W3C standard is 2.2. Regulatory standards tend to follow. Building to 2.2 now means you will not need a second compliance cycle when that alignment happens formally.
Second, the new criteria address UX failures that are extremely common on ecommerce stores specifically. They were written partly because the W3C found that ecommerce checkouts, product listings, and authentication flows were failing users in recurring, systematic ways that WCAG 2.1 did not capture. The criteria are not abstract. They describe things you have almost certainly seen break on your store or your clients’ stores.
Third — and most practically — the fixes for the 2.2 criteria that matter to ecommerce are low-cost. These are not full redesigns. They are CSS minimum sizes, input fields alongside sliders, and billing address pre-fill. The implementation cost is days, not months. The commercial benefit (better usability for everyone, not just users with disabilities) is immediate.
This article covers the five WCAG 2.2 criteria that create the most failures in ecommerce, what failure looks like in practice, and what to fix. For the full WCAG 2.1 AA requirements that the EAA legally mandates, see our European Accessibility Act ecommerce compliance guide.
What changed from WCAG 2.1 to WCAG 2.2
WCAG 2.2 made two structural changes:
Added nine new success criteria. Five are at Level A or AA (the levels EAA requires). Four are at Level AAA (aspirational, not legally mandated). The table below lists the ones relevant to ecommerce:
| Criterion | Level | What it addresses |
|---|---|---|
| 2.4.11 Focus Appearance | AA | Visible focus indicators must meet minimum size and contrast |
| 2.5.7 Dragging Movements | AA | Drag interactions must have a single-pointer alternative |
| 2.5.8 Target Size (Minimum) | AA | Interactive targets must be at least 24×24 CSS pixels |
| 3.2.6 Consistent Help | A | Help mechanisms must appear in the same location on every page |
| 3.3.7 Redundant Entry | A | Users must not be asked to re-enter information already provided |
| 3.3.8 Accessible Authentication (Minimum) | AA | Authentication must not require cognitive tests without alternatives |
Removed one criterion. 4.1.1 Parsing was removed. It previously required valid, clean HTML to ensure assistive technology could parse pages correctly. The W3C removed it because modern browsers now handle malformed HTML gracefully — the failure mode the criterion was designed to prevent no longer occurs in practice.
The five criteria that break most often on ecommerce stores
The following is based on QuickScan audits I’ve run on Dutch ecommerce stores since WCAG 2.2 was published. These are the failures I find in almost every audit.
1. Target Size (2.5.8) — the highest-frequency failure
What it requires: Every interactive element must be at least 24×24 CSS pixels. Alternatively, if an element is smaller than 24×24, there must be at least a 24px offset between it and the nearest other interactive element (so the spacing compensates for the small target).
Why ecommerce fails: Size variant selectors. Filter chips on product listing pages. Quantity increment and decrement buttons. Quick-add icons on product cards. In the Dutch ecommerce stores I audit, these elements are routinely 16×16 or 18×18 pixels in desktop CSS — and even smaller on mobile when percentage-width layouts compress them further.
The most common culprit is the colour/size variant selector on product detail pages. A fashion store listing nine size options in a horizontal strip will often have 16px square tap targets. Users with motor control difficulties cannot reliably tap or click these targets. Neither can many non-disabled users on mobile, which is why high cart abandonment on mobile product pages correlates strongly with small variant selectors.
The 24px offset rule is a partial solution, but it requires deliberate spacing decisions in CSS — it is not automatic. Most stores that technically have small targets are also using tight grid layouts that leave less than 24px between adjacent elements.
Fix: Set a minimum height and width of 24px on all interactive elements in your base CSS. For the actual touch target in mobile contexts, the usability threshold is higher — Apple HIG recommends 44×44px and Google Material Design recommends 48×48px. Meeting the accessibility minimum takes you well below the usability standard. If you are setting 44×44px minimum on mobile (which you should be for CRO reasons independent of accessibility), you automatically exceed the WCAG 2.2 requirement.
/* Minimum to meet WCAG 2.2 — already likely below your usability target */
.variant-selector,
.qty-button,
.quick-add {
min-width: 24px;
min-height: 24px;
}Audit method: open DevTools, inspect each variant selector, filter chip, and icon button. Check the computed width and height. Flag everything under 24px.
2. Redundant Entry (3.3.7) — the billing address problem
What it requires: If a user has provided information in a previous step of a multi-step process, they must not be required to provide the same information again in a later step. Either the system must auto-populate it, or the user must be offered a way to select the previously provided value.
Why ecommerce fails: Billing address. In a standard multi-step checkout, a user enters their name and shipping address on step 1. On step 3 (payment), they are presented with a separate billing address form. If the billing address is the same as the shipping address — which is true for the majority of purchases — requiring re-entry is a WCAG 2.2 Level A failure.
I encounter this in two forms in NL ecommerce audits. The obvious form: no “same as shipping address” option exists at all, and users must retype their full address. The less obvious form: the option exists, but it is not enabled by default, and when a user navigates back through checkout steps and returns to the billing page, the selection is lost and they must check it again.
Forced address re-entry is also a conversion problem independent of accessibility. Baymard’s checkout research identifies it as a contributor to form abandonment, particularly on mobile where retyping is more friction-heavy.
Fix: Display a “same as shipping address” checkbox on the billing step, enabled by default. When a user navigates through checkout steps, persist this selection in session state so it does not reset. Validate that this works both in forward navigation (steps 1→2→3) and backward navigation (returning to step 1 and advancing again).
In Shopify’s native checkout, this is handled correctly by default. The failure most commonly appears in custom checkout implementations, headless builds, or stores using checkout extension apps that inject a separate billing form.
3. Accessible Authentication (3.3.8) — CAPTCHA in your checkout
What it requires: Authentication steps — login, account creation, checkout verification — must not require a cognitive function test unless there is a second mechanism available. A cognitive function test is anything that asks a user to recognize objects, recall information, or solve puzzles — including the “click all images with traffic lights” CAPTCHA format.
Why ecommerce fails: Visual and image-based CAPTCHA on guest checkout or account creation. reCAPTCHA v2 checkbox (the “I am not a robot” checkbox with optional image puzzle) technically requires cognitive function if the puzzle is triggered. Many stores using Shopify or WooCommerce have installed security apps that inject v2 checkbox CAPTCHA at checkout.
An audio CAPTCHA alternative satisfies the requirement, but audio alternatives are frequently absent, poorly implemented, or don’t function when the visual CAPTCHA is JavaScript-injected by a third-party app.
Fix: Switch to reCAPTCHA v3. This is the invisible, score-based version that requires no user interaction at all. It detects bots by analysing behaviour patterns, not by asking users to identify objects. It is more accurate than v2 and fully compliant with 3.3.8.
If you cannot migrate to v3, ensure that an audio alternative is available and functional. Test it: trigger the CAPTCHA puzzle and click the audio icon. Verify it plays, the transcript is accurate, and the audio challenge can be completed without the visual puzzle.
Note: if you are using Shopify Payments, the checkout flow is managed by Shopify and uses v3 by default. The issue arises on account creation pages, subscription apps, or custom checkout flows outside of Shopify’s managed checkout.
4. Dragging Movements (2.5.7) — the price range slider
What it requires: Any functionality that relies on a dragging motion (click and hold, then move) must also be operable with a single pointer action that does not involve dragging. A single click, single tap, or a separate text input are all valid alternatives.
Why ecommerce fails: Price range sliders. These are the most common drag-dependent interaction on ecommerce product listing pages. A dual-handle slider (minimum and maximum price) requires the user to click, hold, and drag to set a price range. There is no standard non-drag alternative unless the developer explicitly provides one.
Product image carousels with drag-to-swipe navigation are a secondary failure. If the only way to advance the carousel is to drag it, users who cannot drag are excluded. (Carousel navigation arrows satisfy the requirement, so this is usually a minor fix — but arrow buttons are frequently hidden or removed in mobile carousel implementations.)
Fix: Add number input fields for minimum and maximum price alongside every range slider. The inputs should be connected to the slider — changing the input updates the slider position, and vice versa. Most modern filter UI libraries support this natively. Custom slider implementations need to add it explicitly.
For carousels, verify that arrow navigation buttons exist and are visible and operable by keyboard. Do not rely solely on swipe gestures.
<!-- Price range with non-drag alternative -->
<label for="price-min">Minimum price</label>
<input type="number" id="price-min" name="price_min" min="0" max="500" value="0">
<input type="range" aria-label="Minimum price" min="0" max="500" value="0">
<input type="range" aria-label="Maximum price" min="0" max="500" value="500">
<label for="price-max">Maximum price</label>
<input type="number" id="price-max" name="price_max" min="0" max="500" value="500">5. Focus Appearance (2.4.11) — the suppressed focus ring
What it requires: The keyboard focus indicator must be visible and meet minimum size and contrast requirements. Specifically, the area in focus state must differ from the unfocused state by at least a 3:1 contrast ratio, and the focus indicator must enclose the focused component with a perimeter of at least 2 CSS pixels.
Why ecommerce fails: Theme base CSS. The single most common accessibility regression I see in ecommerce store themes is outline: none or outline: 0 applied globally in the base stylesheet, often with a comment explaining it was removed for “design consistency.” This removes all keyboard focus indicators from every interactive element on the site.
Without a focus indicator, a keyboard or switch user cannot tell where they are in the page. They cannot navigate your product filters, your checkout form fields, or your payment buttons. The site is effectively unusable for keyboard navigation.
This failure predates WCAG 2.2 — WCAG 2.1 also required focus visibility (criterion 2.4.7). What WCAG 2.2 adds is a specific minimum for the indicator’s size and contrast. But in practice, stores that have suppressed focus rings entirely are failing both 2.1 and 2.2 simultaneously.
Fix: Remove any global outline: none or outline: 0 from your base CSS. Replace with a custom focus style that meets the 3:1 contrast minimum:
/* Remove this — it breaks keyboard navigation */
* { outline: none; }
/* Replace with a visible, high-contrast custom focus indicator */
:focus-visible {
outline: 2px solid #005fcc; /* 4.5:1 contrast on white background */
outline-offset: 2px;
}Use :focus-visible rather than :focus. :focus-visible only displays the focus ring when the user is navigating by keyboard, not when they click with a mouse — this preserves the visual design for mouse users while restoring keyboard navigation for users who need it.
How to audit your store for WCAG 2.2
Automated testing (40% of failures): The Axe DevTools browser extension (free) runs an automated scan of any page and flags WCAG failures. Run it on your homepage, a category page, a product page, and your checkout flow. Automated tests catch contrast failures, missing alt text, invalid ARIA usage, and some focus indicator failures. They do not catch target size, dragging movement, or redundant entry issues — those require manual testing.
Manual testing checklist for WCAG 2.2:
- Measure all variant selectors, filter chips, and icon buttons using DevTools — anything under 24×24px is a 2.5.8 failure
- Navigate through your checkout manually — identify every field where you are asked to re-enter information from a previous step
- Test your checkout authentication flow — trigger any CAPTCHA, verify audio alternative exists and functions
- Identify all drag interactions on product listing pages — verify a non-drag alternative exists for each one
- Remove your mouse and navigate your entire checkout by keyboard only — every step should be completable via Tab, Enter, and arrow keys
- Check your base CSS for
outline: none— remove it and replace with:focus-visiblecustom styles
The WebAIM WCAG 2.2 checklist provides a structured framework for running the full manual pass.
Where WCAG 2.2 fits in your EAA compliance
The EAA legally requires WCAG 2.1 AA. If you are only now beginning EAA compliance work, start there — the EAA ecommerce compliance guide covers what WCAG 2.1 requires in practice for every ecommerce page type.
The five WCAG 2.2 criteria above — particularly 2.5.8 and 3.3.7 — are worth addressing even before 2.2 is formally mandated because they fix UX failures that affect all users. Target size failures and billing address re-entry are conversion problems that show up in session recordings and checkout abandonment data independent of disability context. Fixing them improves your store for everyone.
The implementation cost for all five issues is low. In QuickScan audits, the most common finding is that the largest accessibility improvements require the smallest development changes: a minimum size in CSS, two number inputs next to a slider, a default-checked checkbox, a CAPTCHA library switch. These are hours of work, not months. The barrier is usually awareness, not complexity.
