WCAG 2.2 for e-commerce: what changed and what it means for your store

June 2026 | BarrierScan

The Web Content Accessibility Guidelines version 2.2 were published in October 2023. They are the current version of the W3C accessibility standard that most accessibility requirements reference, including the technical baseline most courts and regulators point to when evaluating whether a website meets accessibility expectations.

If you have been working toward WCAG 2.1 Level AA, you are mostly there. WCAG 2.2 is backward compatible: every criterion in 2.1 remains in 2.2 (one was removed, covered below). The new version adds five criteria at the AA level that require attention, and three at the AAA level that do not. This guide covers the five that matter for e-commerce stores, with concrete examples of what each one requires.

What WCAG 2.2 added at AA

The five new AA success criteria in WCAG 2.2 are:

Criterion	Name	E-commerce relevance
2.4.11	Focus Appearance	Visible focus indicators with minimum area and contrast
2.5.7	Dragging Movements	Carousels, range sliders, and other drag-based controls
2.5.8	Target Size (Minimum)	Small buttons: quantity steppers, wishlist icons, size swatches
3.2.6	Consistent Help	Chat widgets and help links that appear on every page
3.3.7	Redundant Entry	Shipping and billing address fields in checkout

There is also 3.3.8 (Accessible Authentication Minimum), which applies wherever your store requires users to log in or complete a CAPTCHA. It is covered separately below because authentication sits adjacent to checkout in most stores and the practical overlap is high.

2.4.11 Focus Appearance

This criterion requires that the focus indicator on any interactive element meets a minimum visible area and a minimum contrast ratio against its surrounding colors. Specifically, the visible focus indicator must have an area of at least the perimeter of the unfocused component multiplied by 2 CSS pixels, and the color of the indicator must have a contrast ratio of at least 3:1 against adjacent colors.

In practice, the most common failure is suppressing the browser's default focus ring with CSS and not replacing it with anything:

/* This removes focus visibility entirely -- a WCAG 2.4.11 failure */
:focus {
  outline: none;
}

button:focus {
  outline: 0;
}

The fix is to provide a visible focus indicator that meets the area and contrast requirements. The browser default focus ring usually satisfies 2.4.11 if you do not suppress it. If your design requires a custom style, a 2px solid outline with an offset is a reliable approach:

/* Replace outline: none with a custom visible ring */
:focus-visible {
  outline: 2px solid #b45309;
  outline-offset: 2px;
}

/* Never set outline: none unless you have a complete replacement */

Note the use of :focus-visible rather than :focus. The :focus-visible pseudo-class only applies when the browser determines that the focus indicator should be shown -- typically for keyboard navigation but not for mouse clicks that do not benefit from a visible indicator. This preserves clean mouse interaction while satisfying the keyboard accessibility requirement.

Most e-commerce themes strip focus rings for aesthetic reasons. Running a keyboard-only navigation test through your product page, cart, and checkout will reveal whether users who rely on keyboard navigation can see where they are on the page. Any button, link, or input that shows no visible indicator when focused is a potential 2.4.11 failure.

2.5.7 Dragging Movements

This criterion requires that any operation that can be performed by dragging can also be performed with a single pointer action (a click, tap, or keyboard operation). The point is that some users cannot perform controlled drag movements: users with motor impairments, users on switch access devices, or users with limited dexterity.

On e-commerce stores, this comes up most often in two places.

Product carousels and image sliders

A carousel that moves only by touch swipe, with no previous and next buttons, fails 2.5.7. Any swipe-or-drag interface needs a pointer-based alternative:

<!-- Carousel needs keyboard-accessible prev/next controls -->
<button class="carousel-prev" aria-label="Previous image">
  <svg aria-hidden="true" viewBox="0 0 24 24">...</svg>
</button>

<div class="carousel-track" role="region" aria-label="Product images">
  <!-- slides -->
</div>

<button class="carousel-next" aria-label="Next image">
  <svg aria-hidden="true" viewBox="0 0 24 24">...</svg>
</button>

Price and filter sliders

Range inputs used for price filters or product dimension selectors may implement custom drag handles. If the only way to change the value is to drag a handle, you need an alternative. The native HTML <input type="range"> element satisfies this requirement by default because it accepts arrow key input. Custom slider implementations need to add keyboard event handling that replicates the drag behavior:

<!-- Custom slider: add keyboard support -->
<div role="slider"
  aria-label="Maximum price"
  aria-valuemin="0"
  aria-valuemax="500"
  aria-valuenow="250"
  aria-valuetext="$250"
  tabindex="0"
  id="price-max">
</div>

<script>
document.getElementById('price-max').addEventListener('keydown', function(e) {
  const step = 10;
  if (e.key === 'ArrowRight' || e.key === 'ArrowUp') {
    // increase value
  }
  if (e.key === 'ArrowLeft' || e.key === 'ArrowDown') {
    // decrease value
  }
});
</script>

2.5.8 Target Size (Minimum)

Interactive elements must have a minimum target size of 24 by 24 CSS pixels. This criterion applies to elements where the spacing between interactive targets does not provide equivalent reach: if two small buttons are packed together with no gap, a user may tap the wrong one. The intent is to prevent situations where very small touch targets cause errors for users with motor impairments or those on touch devices.

The 24x24 pixel requirement applies to the target area, not the visual size of the icon or label. An icon-only button can display a 16x16 icon as long as its clickable area is at least 24x24. CSS padding is the usual mechanism:

<!-- Wishlist icon: visual icon is 16x16 but tap target is 24x24+ -->
<button class="wishlist-btn"
  aria-label="Save Linen Tote Bag to wishlist"
  style="padding: 8px; line-height: 0;">
  <svg aria-hidden="true" width="16" height="16" viewBox="0 0 16 16">...</svg>
</button>

Elements that most commonly fail this criterion on e-commerce stores:

Quantity increment and decrement buttons on product pages and cart lines
Small color or size swatch buttons in a dense variant grid
Wishlist, compare, and remove icons on product tiles
Close buttons on notification banners and cookie consent dialogs
Pagination links rendered as small numbers with tight spacing

There is an exception: if the element is inline within text (a link within a paragraph), the 24x24 requirement does not apply. The criterion is aimed at controls, not inline hyperlinks.

3.3.7 Redundant Entry

This criterion applies to multi-step processes where users might need to enter the same information more than once. It requires that previously entered information be either auto-populated, selectable, or otherwise available without requiring re-entry. Users who have cognitive disabilities, motor impairments, or who are using dictation software may find repeated data entry significantly more burdensome than a typical user.

The most direct e-commerce application is the checkout shipping and billing address flow. If a user enters their shipping address and then has to re-type the same address in the billing section, that is a redundant entry failure unless the billing section pre-fills from the shipping data or the user can check a box to copy it over.

The expected pattern:

<!-- Billing address section in checkout -->
<fieldset>
  <legend>Billing address</legend>

  <label>
    <input type="checkbox" id="billing-same" name="billing-same">
    Same as shipping address
  </label>

  <!-- When checked, billing fields are hidden or auto-populated -->
  <div id="billing-fields">
    <label for="billing-street">Street address</label>
    <input type="text" id="billing-street" name="billing-street"
      autocomplete="billing street-address">
    <!-- etc -->
  </div>
</fieldset>

<script>
document.getElementById('billing-same').addEventListener('change', function() {
  const billingFields = document.getElementById('billing-fields');
  if (this.checked) {
    // copy shipping values into billing fields or hide them
    billingFields.hidden = true;
  } else {
    billingFields.hidden = false;
  }
});
</script>

The same principle applies to account registration flows where a user sets an email during checkout and is then prompted to enter it again for account creation, or to loyalty program enrollment that asks for information the user already provided at signup.

3.3.8 Accessible Authentication (Minimum)

This criterion requires that authentication processes not rely on a cognitive function test unless an alternative is provided. The practical target is CAPTCHAs: a puzzle-style CAPTCHA that requires identifying objects in images is a cognitive function test, and it fails this criterion unless there is an alternative method of authentication available, such as an email confirmation link or a simple verification code.

For most e-commerce stores, authentication happens at account login and, for guest-to-account conversion, at checkout. Two things to check:

First, if your login or checkout flow includes a third-party CAPTCHA service (Google reCAPTCHA, hCaptcha, Cloudflare Turnstile), verify that it offers a non-puzzle alternative. reCAPTCHA v3 and Cloudflare Turnstile operate invisibly in the background without requiring user interaction, which avoids the criterion entirely. hCaptcha puzzle mode requires a fallback. The invisible or risk-score-based variants satisfy 3.3.8 because they do not require the user to perform a cognitive task.

Second, if your store implements any custom authentication challenge, provide an alternative. Email-based one-time codes, SMS codes (with the understanding that SMS is not universally accessible), or magic links all provide an alternative that does not depend on solving a visual puzzle.

What was removed: 4.1.1 Parsing

WCAG 2.2 formally removed Success Criterion 4.1.1 Parsing, which previously required that HTML be well-formed with properly nested elements and unique IDs. The removal reflects current browser behavior: modern browsers repair malformed HTML gracefully and present a consistent DOM to assistive technologies regardless of markup errors. The issues that 4.1.1 was designed to prevent (assistive technologies failing due to malformed HTML) are no longer a realistic concern. If your older audit reports flag this criterion, the finding is no longer relevant under 2.2.

How WCAG 2.2 relates to ADA compliance

Automated scanning covers the majority of issues that appear in e-commerce ADA web cases, but it cannot cover everything. This post describes specific technical criteria, not legal compliance guarantees.

Most ADA web accessibility lawsuits filed against US businesses cite WCAG 2.0 or 2.1 Level AA as the technical standard. The Department of Justice final rule for ADA Title II (published March 2024) requires WCAG 2.1 Level AA for state and local government websites. Private businesses covered by Title III do not have a codified standard in the final rule, but WCAG 2.1 AA is the de facto reference.

WCAG 2.2 is backward compatible with 2.1. Meeting WCAG 2.2 AA means you also meet 2.1 AA on every criterion that 2.1 includes. Aiming for 2.2 is the most current target and avoids having to revisit these new criteria later as enforcement and litigation patterns catch up to the current spec.

Focus Appearance (2.4.11) and Target Size (2.5.8) are among the most common practical failures in real e-commerce codebases. They are also the most likely to generate complaints from users who rely on keyboard navigation or touch devices, regardless of whether those complaints escalate to legal action.

Checking your store

Some of the new criteria are checkable by automated scanning. Focus Appearance violations are partially detectable: a scan can identify elements where outline: none is applied without a replacement, though it cannot fully evaluate the visual area and contrast requirements without rendering the page. Target Size failures are harder for automated tools because the clickable area depends on padding and computed CSS that varies by device. Dragging Movements and Redundant Entry require functional testing to evaluate properly.

For a practical start: tab through your store with only a keyboard and note every element where the focus indicator is invisible. Then measure the tap targets on your quantity buttons, wishlist icons, and close buttons. Those are the highest-frequency failures in this version of the spec on e-commerce stores.

If you want a full scan that checks WCAG 2.1 AA issues (which make up the bulk of detectable e-commerce accessibility failures), request a free accessibility scan and we will run your site and send you the report.