WCAG 2.2 for Ecommerce: What Changed, the New Lawsuit Targets, and a Practical Compliance Checklist
WCAG 2.2 introduced nine new success criteria. ADA lawsuits against ecommerce sites hit record numbers in 2025. Here's what's actually testable, what plaintiffs' lawyers are looking for, and how to fix the highest-risk issues.
Ecommerce sites were the most-sued category for ADA accessibility lawsuits in 2025, with over 4,000 federal complaints filed and an estimated 8,000+ demand letters that never made it to court. The plaintiffs' bar has industrialized the process: automated scans of thousands of sites at a time, demand letters generated by template, settlements negotiated for $5,000–$25,000 each, and minimal cost to the plaintiff law firm per case.
WCAG 2.2 is now the de-facto standard courts reference (W3C published 2.2 in October 2023, and it's been incorporated into Section 508 and most state-level accessibility statutes). It adds nine new success criteria on top of WCAG 2.1. Most stores tested only against 2.0 or 2.1 — meaning the new criteria are fresh fishing grounds for the plaintiffs' bar.
This guide covers what's new in WCAG 2.2, which criteria the lawsuit demand letters are actually testing for, and a practical fix checklist ranked by lawsuit risk.
What's New in WCAG 2.2 (Compared to 2.1)
Nine new success criteria. Six are Level A or AA (the levels referenced by lawsuits); three are Level AAA (rarely required).
2.4.11 Focus Not Obscured (Minimum) — Level AA
When a user tabs to an element via keyboard, the focused element must not be entirely hidden by sticky headers, cookie banners, chat widgets, or other overlays. This is a top-3 lawsuit target because most ecommerce sites have a sticky header that scrolls content underneath, and the focus indicator on a deep-in-page element gets covered by the header.
2.4.12 Focus Not Obscured (Enhanced) — Level AAA
Stricter version: focused element cannot be partially obscured. Rarely tested in lawsuits.
2.4.13 Focus Appearance — Level AAA
Minimum size and contrast requirements for the focus indicator outline. AAA level, less commonly enforced.
2.5.7 Dragging Movements — Level AA
Any drag-and-drop interaction must have a non-drag alternative. Affects product image carousels with drag interactions, image zoomers, color swatch carousels, and "drag to reorder" wishlist functionality. Plaintiffs increasingly cite this for product image galleries with no swipe alternative.
2.5.8 Target Size (Minimum) — Level AA
Interactive targets must be at least 24×24 CSS pixels. This catches: small "x" close buttons on modals, small swatch selectors for color/size, small checkbox/radio buttons in filter sidebars, small "remove from cart" buttons, and small social-share icons. Mobile-responsive sites often fail this on the desktop view at narrow widths where targets shrink.
3.2.6 Consistent Help — Level A
If a help mechanism (search, chat, contact info) is provided on a set of pages, it must appear in the same relative order on every page. Affects sites that move the chat widget to the footer on some pages but to the corner on others.
3.3.7 Redundant Entry — Level A
Users must not be required to re-enter information they already provided during the same process. Affects: checkout flows that ask for "shipping address" then on the next step ask for "billing address" without an option to "copy shipping address." Most lawsuit demand letters cite this against the checkout flow.
3.3.8 Accessible Authentication (Minimum) — Level AA
Login and authentication processes cannot require a cognitive function test (remembering a password, solving a CAPTCHA, etc.) without an accessible alternative. This effectively requires offering: password manager autofill support (don't block paste in password fields), passkeys/biometric login, or "send a login code to my email." Sites that block password manager autofill or require image-based CAPTCHA without an audio alternative fail this.
3.3.9 Accessible Authentication (Enhanced) — Level AAA
Stricter version that prohibits cognitive function tests even with alternatives. Rarely enforced.
What the Plaintiffs' Lawyers Actually Test For
Demand letters in 2025 most commonly cited (in rough order of frequency):
- 1.1.1 Non-text Content (alt text) — Level A. Missing or unhelpful alt attributes on product images. Easy to detect, easy to plead.
- 1.4.3 Contrast (Minimum) — Level AA. Insufficient color contrast on body text, button labels, link text. Most commonly cited against gray-on-gray sale price text and pale brand color schemes.
- 2.4.4 Link Purpose (In Context) — Level A. "Click here," "Read more," "Shop now" links without sufficient context for screen reader users.
- 3.3.7 Redundant Entry — Level A. Checkout requires re-entering shipping address as billing address.
- 2.5.8 Target Size — Level AA. Small interactive elements, especially on mobile.
- 4.1.2 Name, Role, Value — Level A. Custom dropdowns and form controls without proper ARIA labeling.
- 2.4.11 Focus Not Obscured — Level AA. Focus indicator hidden under sticky header.
- 3.3.2 Labels or Instructions — Level A. Form fields without programmatic labels (only placeholder text).
- 2.1.1 Keyboard — Level A. Functionality requiring mouse (often the price slider or color swatches).
- 1.3.5 Identify Input Purpose — Level AA. Checkout form fields not using
autocompleteattribute correctly.
Practical Fix Checklist (Ranked by Lawsuit Risk)
Tier 1: Fix this week (top lawsuit triggers)
- Alt text on every image: particularly product images, decorative banners, hero images. Empty
alt=""is acceptable for purely decorative; never omit the attribute entirely. Run an automated scan with axe or WAVE. - Add "copy shipping to billing" checkbox: at the billing address step, default the checkbox to checked. One CSS line and a JS handler.
- Color contrast audit: use the Chrome DevTools color contrast checker on every text color in your design system. Target 4.5:1 for normal text, 3:1 for large text. Brand gray
#888on white is 3.0:1 — fails. Use#666minimum. - Form labels: every
<input>needs a programmatic<label>. Placeholder-only labels fail. Addaria-labelwhen a visible label isn't possible. - Sticky header focus: add
scroll-padding-top: [header-height]to:rootin CSS. Modern browsers respect this for keyboard scrolling and avoid focus-under-header.
Tier 2: Fix this month (commonly cited)
- Target sizes: audit close buttons, swatch selectors, social icons. Minimum 24×24px (use padding to expand the clickable area without enlarging the visual).
- Link text: replace generic "Click here" and "Read more" with descriptive text. If visual layout requires the short text, use
aria-labelon the link to provide context. - Drag-and-drop alternatives: if you use a draggable product image carousel, add visible left/right arrow buttons that scroll the carousel. Both must work.
- CAPTCHA alternative: if you use Google reCAPTCHA v2, enable the audio challenge alternative. Better: switch to reCAPTCHA v3 (invisible) or Cloudflare Turnstile, neither of which require a cognitive test.
- Autocomplete attributes: on checkout forms, add
autocomplete="given-name",autocomplete="family-name",autocomplete="street-address",autocomplete="cc-number", etc. Required by WCAG 2.2 AA and improves checkout conversion 5–15%.
Tier 3: Strategic improvements
- Skip navigation link: first focusable element on every page should be "Skip to main content."
- ARIA landmarks: use
<header>,<nav>,<main>,<footer>elements or appropriate ARIA roles for accurate landmark navigation. - Focus visibility on all interactive elements: never use
outline: nonewithout providing an alternative focus style. The default browser focus ring is ugly but accessible. - Modal focus trap: when a modal opens, focus moves to inside the modal; Tab cannot leave the modal until it closes; Escape closes the modal.
- Accessibility statement page: publish a /accessibility-statement page. Acknowledges your commitment, provides contact info for accessibility issues, lists tools used to test. Demand letters sometimes drop when an accessibility statement is published because it shows good faith.
Overlays and "Accessibility Widgets" — A Trap
AccessiBe, UserWay, AudioEye, equallyAI, and similar "one-line install" accessibility overlays have been the subject of their own lawsuits. Plaintiffs' lawyers now specifically target sites using overlays because the overlays often don't fix the underlying issues (they layer on top of inaccessible HTML) and create a record that the site owner knew they had accessibility problems and tried to "solve" with a widget instead of remediation.
If you currently use an overlay, your legal exposure may be higher than if you'd done nothing. The remediation path is to fix the underlying HTML/CSS/JS and remove the overlay.
Automated Testing Gets You 30%
Tools like axe DevTools, Lighthouse's accessibility audit, WAVE, and the Pa11y CLI catch 25–35% of WCAG issues automatically. The other 65%+ require manual review with a screen reader (NVDA on Windows, VoiceOver on Mac) or hiring a third-party accessibility audit. For most ecommerce stores, the cost-effective approach is:
- Run automated tools weekly (catch regressions)
- One annual third-party audit ($3,000–$15,000 depending on site complexity)
- Test with a screen reader on the top 5 user flows (homepage, category, product, cart, checkout) quarterly
What to Audit Now
- Open your homepage in Chrome. Run Lighthouse accessibility audit. Note all issues.
- Tab through your homepage with keyboard only. Can you reach every interactive element? Is the focus indicator always visible (not hidden under header)?
- Open your checkout flow. Test whether shipping address can be copied to billing without re-typing. If not, this is your single highest lawsuit risk fix.
- Inspect form fields on checkout. Verify each has a programmatic
<label>oraria-label. Verify each has the correctautocompleteattribute. - Use the Chrome DevTools color picker on every text color on every page template. Verify minimum 4.5:1 contrast against the background.
- If you have an accessibility overlay (AccessiBe, UserWay, etc.), plan its removal and replacement with native remediation.
The Underlying Truth
WCAG 2.2 didn't fundamentally change accessibility — it formalized criteria that good developers were already meeting. The lawsuit risk hasn't increased because of WCAG 2.2; the lawsuit risk has increased because the plaintiffs' bar has industrialized detection and the new criteria are fresh targets. For ecommerce stores, the most cost-effective response is fixing the top 10 most-cited criteria (most are quick technical fixes) and publishing an accessibility statement. The legal cost of one demand letter is typically 5–10x the cost of full remediation, which is why this is a "fix once, save many times" problem.
Run a StoreVitals scan. We check form labels, ARIA landmarks, skip navigation, alt text presence, color contrast on key elements, and empty links — covering the foundational layer of automated WCAG checks. Use it weekly to catch regressions, and pair with a third-party manual audit annually for full coverage.