Compliance & Lawsuits

The Ecommerce Accessibility Playbook: Why 69-77% of ADA Lawsuits Target Online Stores

A funnel-by-funnel guide to the WCAG issues that put online stores in the lawsuit crosshairs — and how to fix them in code, not with a widget.

Last updated May 24, 2026

Ecommerce is where the ADA web-accessibility lawsuit volume actually lives. Per TestParty's analysis of H1 2025 lawsuit data, ecommerce sites accounted for 69–77% of all H1 2025 ADA web-accessibility filings (TestParty H1 2025 lawsuit trends). The concentration is not random. Online stores are publicly discoverable, transactional, and full of clear “barriers to purchase” that a plaintiff's firm can document on a fifteen-minute keyboard test. The same firms that filed the bulk of 2024 cases continue to file at high volume in 2025, and they prefer targets they can pattern-match cheaply.

Size is not protection. Per UsableNet's 2024 Year-End Report (as cited by TestParty.ai): 67% of ADA website lawsuits targeted companies with less than $25 million in annual revenue (UsableNet research). The mid-market and small-business merchant who assumes plaintiffs' firms will go after Fortune 500 retailers first has the math backwards: the small store is the easier, cheaper, more settle-friendly target.

Platform choice changes the baseline but does not eliminate the problem. Per WebAIM Million 2025: Shopify averaged 69.6 errors per home page; WooCommerce averaged 75.6; Magento averaged 85.4. Average across all sites was 50.96 (WebAIM Million 2025). Every major ecommerce CMS scored worse than the web average on the home page alone, and the home page is the easiest surface to audit. Category pages, product pages, cart, and checkout are typically worse.

The funnel matters. Most WCAG issues that drive ecommerce demand letters concentrate in three places: the product detail page (image galleries, variant pickers, add-to-cart announcements), the cart (icon-only remove buttons, cart updates not announced to screen readers), and the checkout (form labels, error messages, multi-step progress, payment iframes). SweepHound's framing throughout this guide is code-level remediation, not widget overlays. Below we walk step by step through that funnel, name the WCAG Success Criteria most often cited, and give you a sequenced playbook for audit and fix.

Why ecommerce is the lawsuit epicenter

A demand letter under Title III of the ADA generally needs to show two things: that the site is a place of public accommodation under the prevailing circuit law, and that the plaintiff personally encountered a barrier that prevented them from accessing goods or services. Ecommerce sites map onto both prongs with unusual neatness. They are public-facing, they exist precisely to sell goods, and the barriers a plaintiff cites — a checkout form they could not complete, a product image without alt text, a cart update they could not perceive — are concrete and easy to document in a screen recording.

Ecommerce sites are also data collectors. The plaintiff's firm can show, with timestamps, that the user attempted to log in, attempted to filter a category, attempted to submit a coupon code — and that the keyboard, the screen reader, or the live region failed them at a specific step. That is qualitatively different from a brochure-ware site where the only allegation is that decorative imagery lacks alt text. The friction is transactional, which makes the harm easier to plead.

The plaintiffs' bar in this space is concentrated. A small number of high-volume claimants and their counsel file most web-accessibility cases. Their workflow is templated: pull a list of ecommerce sites, run a quick keyboard or screen-reader pass, draft letters or complaints from a library of known WCAG citations. The marginal cost of adding your store to that list is low. The marginal cost to you of a settlement plus remediation is not. For context on overall filing volume, see Seyfarth Shaw's ongoing tracker (adatitleiii.com), and read our demand-letter response playbook for what to do if a letter has already arrived.

There is also a structural reason ecommerce keeps making the list: the way most stores are built today layers third-party JavaScript on top of a customizable theme on top of a platform shell. Each layer can independently regress accessibility, and most merchants do not own end-to-end test coverage that would catch a regression before deploy. A new email-capture popup, a new review widget, a new shipping calculator, a new chat tool — any of these can break focus order, hijack the tab key, or paint over a visible focus ring in a way that turns a clean homepage into a letter-worthy one without any code change on your part. The result is that accessibility status drifts even when nothing in the merchant's own theme has changed, which is why monitoring matters more than a one-time audit.

The ecommerce funnel and where issues live

The fastest way to think about ecommerce accessibility is as a journey from arrival to support. Each step has its own family of WCAG issues, and a defensible audit covers every step. Skipping checkout because it “just uses Stripe” is one of the most common ways merchants under-scope a remediation effort.

Homepage

The homepage is the page plaintiffs see first, and it is almost always tested by the lawsuit-screening pass. Three components fail most often: the banner carousel, the hero call-to-action, and the search bar. Auto-rotating carousels frequently lack pause controls (WCAG 2.2.2 Pause, Stop, Hide) and use slide indicators that are not reachable or operable by keyboard. Hero CTAs frequently fail color contrast against gradient or photographic backgrounds (1.4.3 Contrast Minimum), and the focus ring — if it exists at all — often disappears against the same backgrounds (2.4.7 Focus Visible). Search bars in custom themes commonly ship without a label, without an associated form landmark, and with autosuggest dropdowns that do not implement the combobox pattern. The main navigation is the other dense failure surface: mega menus that open on hover with no keyboard or focus equivalents, language and currency switchers that announce themselves only by flag image, and skip-link patterns that target an element which is not in fact the start of main content.

Category and product listing page (PLP)

The PLP is dense with custom UI: filter sidebars, sort dropdowns, infinite scroll, color swatches, sale tags, quick-view modals. Each one is a candidate for a citation. Filter checkboxes are often implemented as styled divs with no role or name (4.1.2 Name, Role, Value). Sort dropdowns are sometimes pure-CSS menus that cannot be opened with the keyboard (2.1.1 Keyboard). Infinite scroll without a “load more” affordance traps screen-reader users who cannot perceive that new content has appeared (and breaks 2.4.1 Bypass Blocks for the footer beneath it). Product cards lean heavily on imagery: missing or unhelpful alt text (1.1.1 Non-text Content) on the primary product image, sale tags rendered only as color (1.4.1 Use of Color), and color swatches with no accessible name for each variant. See our alt-text guide for what good descriptions look like for product photography.

Product detail page (PDP)

The PDP is the single most-audited page on most ecommerce sites, because it contains the decision point. Image galleries with thumbnails are often un-labeled and rely on click handlers attached to non-interactive elements. Variant selectors (size, color, fit) are frequently rendered as styled buttons or links with no group label and no indication of the currently selected value. The add-to-cart button itself usually works, but the resulting state change — “Item added to cart” — is rarely announced via an aria-live region, leaving screen-reader users to guess whether anything happened. Quantity steppers are typically two icon buttons with no accessible name. Reviews modules pull in star ratings rendered as background images without text alternatives. Cross-sell carousels repeat the same accessibility issues as the home banner.

Cart

The cart is small, but punches above its weight in citations. When a line-item quantity changes or a coupon applies, the cart total updates silently in the DOM. Screen-reader users do not perceive the change unless the updating region is wrapped in aria-live="polite" with sensible aria-atomic semantics (4.1.3 Status Messages). Remove buttons are routinely rendered as icon-only X glyphs with no name (2.5.3 Label in Name, 4.1.2 Name, Role, Value). Coupon application forms frequently lack labels and submit via a button that looks like a link, breaking 1.3.1 Info and Relationships. Mini-cart drawers that slide in from the right are often built without focus trap or restoration logic, which maps to keyboard traps and disorientation when the drawer closes.

Empty-cart states deserve their own attention. When a user removes the last item, the cart should announce the new state and present a focusable element — a continue-shopping link, for example — rather than collapsing to a static line of text with focus orphaned somewhere off-screen. Free-shipping progress meters, gift message inputs, and tip selectors are recent additions to most carts and tend to ship with the same issues as the rest of the page: unlabeled inputs, color-only progress indicators, and toggle buttons whose pressed state is not exposed to assistive technology.

Checkout

Checkout is the highest-stakes surface in the whole funnel and the one merchants most often under-test, because they assume the payment vendor handles it. Multi-step checkouts need a clear, programmatic indication of the current step (1.3.1 Info and Relationships). Address auto-fill needs proper autocomplete attributes on each field (1.3.5 Identify Input Purpose). Validation errors must be associated with their fields via aria-describedby and announced as the user makes mistakes (3.3.1 Error Identification, 3.3.3 Error Suggestion). Password fields and login flows must conform to 3.3.8 Accessible Authentication: do not impose cognitive function tests like recall puzzles unless an alternative exists. Order summaries that update when shipping changes need a live region, exactly like the cart total. See our form validation guide for the underlying patterns.

Payment iframes — Stripe Elements, PayPal Buttons, Apple Pay, Klarna — carry their own internal accessibility, but they remain on your page. You are responsible for how they are framed: their container needs a sensible label, focus order needs to flow into and out of the iframe naturally, and any error messages or fallbacks rendered by your code (not the vendor's) must obey the same rules as the rest of your forms.

Guest-checkout and account-required toggles deserve a careful review too. A common pattern is to surface a single radio group at the top of checkout for “Sign in” versus “Check out as guest,” built with custom-styled radios whose role and checked state are not exposed correctly. Plaintiffs cite the inability to choose guest checkout as a barrier to purchase disproportionately often, because the alternative requires the user to complete a separate sign-in flow that may itself be inaccessible.

Account and login

Login forms are the second-most-common surface plaintiffs test, and the password manager friendliness requirements in 3.3.8 Accessible Authentication (WCAG 2.2) are increasingly cited. Do not block paste into the password field, and do not require users to retype values they should be able to paste. Authenticated areas — order history, address book, saved payment methods — need everything the storefront needs: form labels (3.3.2 Labels or Instructions), keyboard operability (2.1.1, 2.1.2 No Keyboard Trap), and visible focus (2.4.7). Table-based order history needs proper header cells (1.3.1).

Support

Chat widgets are the single biggest source of regression on otherwise-clean stores. Most third-party chat tools inject their own focus management, modal behavior, and live regions, and they interact poorly with your theme. Test that the chat launcher has a name (4.1.2), that the chat window can be reached and dismissed by keyboard (2.1.1), and that incoming messages are announced (4.1.3). Contact forms and help-article pages should follow the same form and heading rules as the rest of the site. Returns and exchange flows hidden behind an account section deserve the same audit attention as checkout: they are transactional surfaces in their own right.

Common WCAG citations at each step

The Success Criteria below appear in the overwhelming majority of ecommerce demand letters and complaints. If your audit catches all of these across the funnel, you have already cleared most of what a templated plaintiff's firm will look for.

• 1.1.1 Non-text Content— product images, sale tags, social icons, payment-method icons.
• 1.3.1 Info and Relationships — checkout step indicators, order summary tables, form grouping for variant pickers.
• 1.3.5 Identify Input Purpose — address and payment field autocomplete attributes.
• 1.4.3 Contrast (Minimum) — price text, sale badges, hero CTAs over imagery. See our color contrast guide.
• 1.4.11 Non-text Contrast — form-field borders, focus rings, icon buttons.
• 2.1.1 Keyboard / 2.1.2 No Keyboard Trap — mega menus, quick-view modals, mini-cart drawers, chat widgets. Read our keyboard traps guide.
• 2.2.2 Pause, Stop, Hide — auto-rotating hero carousels.
• 2.4.7 Focus Visible— CTAs, swatches, dropdowns whose focus styles were removed by the theme.
• 2.5.3 Label in Name / 2.5.8 Target Size (Minimum) — icon-only buttons, quantity steppers, remove-from-cart X buttons. 2.5.8 is new in WCAG 2.2 and applies broadly across ecommerce. See the WCAG 2.2 checklist.
• 3.3.1, 3.3.2, 3.3.3, 3.3.4 Errors and Labels — checkout validation, login forms, coupon entry.
• 3.3.8 Accessible Authentication — password fields, “type the word above” puzzles, paste blockers (WCAG 2.2).
• 4.1.2 Name, Role, Value / 4.1.3 Status Messages — styled-div controls, cart updates, error toasts, mini-cart line additions.

Why widgets and overlays make ecommerce worse, not better

Ecommerce merchants get more overlay sales pitches than any other vertical. The pitch is always the same: install a script tag, become compliant. The Federal Trade Commission has now formally rejected the marketing claims those products are built on. On April 22, 2025, the FTC approved a final consent order requiring accessiBe to pay $1 million, barring accessiBe from representing that its automated products can make any website WCAG-compliant or can ensure continued compliance with WCAG over time, unless it has the evidence to support such claims (FTC press release). In ecommerce specifically the math is worse: an overlay cannot add a missing label to a Stripe iframe, cannot announce a cart update from your headless front-end, and cannot fix a variant picker built with non-interactive elements. It can, however, be cited in a complaint as a barrier. Read the full breakdown in our accessibility overlays guide.

Platform-specific posture

No mainstream ecommerce platform ships clean. The WebAIM Million 2025 numbers below set a useful baseline for “what does this platform do before your theme touches it.” A custom theme can improve or worsen these numbers significantly — treat the table as a starting expectation, not a finished audit.

Each major platform has its own remediation patterns — Liquid for Shopify, PHP/Twig for Magento, Gutenberg blocks for WooCommerce, a visual editor for Wix and Squarespace. The WCAG ceiling is the same. The fix surface is not. Hosted platforms (Wix, Squarespace, BigCommerce) constrain what you can change in the underlying HTML but ship more accessible defaults; self-hosted platforms (WooCommerce, Magento) give you full control of the markup but also full control of the regressions. Headless stacks (Hydrogen, Vue Storefront, Next.js Commerce front-ends) live in a separate world: the platform's default checkout is irrelevant because you have rebuilt it, and you own every line of the funnel.

• Shopify — Shopify accessibility guide
• WooCommerce — WooCommerce accessibility guide
• Magento / Adobe Commerce — Magento accessibility guide
• Wix — Wix accessibility guide
• Squarespace — Squarespace accessibility guide
• BigCommerce — BigCommerce accessibility guide
• Webflow — Webflow accessibility guide
• WordPress (non-Woo content) — WordPress accessibility guide

An audit-and-remediation playbook for ecommerce sites

A defensible ecommerce remediation effort is sequenced. Trying to fix everything from a flat issue list, in any order, will leave gaps at exactly the funnel steps plaintiffs test first. The following sequence trades a little speed for a lot of legibility, which is what counsel will want to point at if a letter ever arrives. Throughout, keep raw scan artifacts, dated screenshots, and version-controlled commits as the spine of the record — the deliverable that matters is not a green dashboard, it is a dated paper trail showing what you knew, when you knew it, and what you did about it.

1. Scan with a dual-engine automated tool. Per Deque's Automated Accessibility Coverage Report, Deque reported automated tests identified 57.38% of issue instances by volume in its dataset — based on 2,000+ audits across 13,000+ pages and ~300K issues (Deque coverage report). That is a floor, not a ceiling, and a single engine misses things a second engine catches. Crawl the whole site, not a sample of pages.
2. Triage by funnel step, not by rule. Group the issues into homepage / PLP / PDP / cart / checkout / account / support buckets. Sort within each bucket by how user-visible the failure is. The first ten fixes that move the needle on a complaint are almost always at checkout, cart, and login — not in the footer.
3. Fix at the source code level. Edit templates, components, and theme partials directly. Commit the changes. Each commit message should reference the WCAG Success Criterion it addresses, and each PR should link the scan artifact that surfaced the issue. This is the artifact counsel will rely on.
4. Manually verify cart and checkout on keyboard and screen reader. Add an item to cart with no mouse. Update quantity. Apply a coupon. Proceed to checkout. Submit a form with errors and recover. Repeat with VoiceOver on macOS or NVDA on Windows. Read our manual checklist and what scanners miss for the categories that automation cannot cover.
5. Publish an accessibility statement. Date it. List the standards you are targeting. Name a contact address for users who hit a barrier. Use our statement generator as a starting point and edit for accuracy.
6. Monitor on a schedule. Themes change. Apps update. New product templates ship. A once-a-year audit is not enough. Re-scan at least monthly, and run a fresh manual pass before every major release.

If you have already received a demand letter

The order of operations changes. Forward the letter to counsel first; do not start visible remediation before counsel is engaged; do not install an overlay mid-case. The defensible-remediation posture matters more than chasing 100% conformance, because conformance is not the standard the court will measure. See our ADA demand letter response playbook for the 48-hour sequence.

How SweepHound supports ecommerce sites

SweepHound is built for the way ecommerce sites actually fail. Instead of a single-page scan or a runtime widget, it crawls your whole store so cart, checkout, account, and PDP variants all surface in the same report. It uses two scan engines (axe-core and IBM Equal Access) so issues missed by one are usually caught by the other, and it generates code-level remediation suggestions referencing the actual templates and components your developers edit — not generic “add an alt attribute” advice.

Scans run on a schedule you set, so theme updates and new product templates do not silently regress. Each scan produces a public, shareable report you can hand to a developer, an agency, or counsel without sending them a login. None of this makes your store ADA-compliant on a checklist; it gives you the kind of documented, dated, code-level remediation record that maps onto the defensible-remediation posture this guide has described. Start with a free scan and see what a full-funnel report looks like, or compare plans on the pricing page. When you are ready to put the playbook into motion, you can start your audit here.