Online retail sits on top of the ADA website lawsuit list year after year. In 2023 and 2024, the single largest category of Title III digital accessibility filings was ecommerce, and the pattern has held into 2025. Ecommerce accessibility compliance has a sharper edge than compliance for most other site types, because the failure is not abstract —.
Online retail sits on top of the ADA website lawsuit list year after year. In 2023 and 2024, the single largest category of Title III digital accessibility filings was ecommerce, and the pattern has held into 2025. Ecommerce accessibility compliance has a sharper edge than compliance for most other site types, because the failure is not abstract — a screen reader user who cannot complete a purchase has been denied access to goods or services, which is exactly the language plaintiffs' firms build complaints around. An ecommerce web design partner that ignores accessibility is shipping a liability, not just an inconvenience.
Why the Ecommerce Journey Fails More Than Other Sites
A marketing site has a bounded set of pages and fairly linear user flows. An online store has dynamic filters, variant selectors, cart updates, inventory changes, promo code fields, third-party payment iframes, and post-purchase state — each of which is a separate place where accessibility can break. The 2019 Supreme Court denial of cert in Robles v. Domino's cemented that commercial websites are places of public accommodation under the ADA, and the follow-on case law has specifically targeted the transactional depth that sets ecommerce apart.
Plaintiffs' firms have templated their complaints around the specific checkout failure points. The pattern is consistent: the home page is usually fine, the category pages are mostly fine, and the wheels come off at filter interactions, variant selection, and checkout. This is where testing has to concentrate and where most ecommerce platforms out of the box leave the most work to do.
Faceted Filters: The First Major Break Point
Filter controls on a category page are almost universally built as custom interactive components rather than native checkboxes or radio buttons. The visual pattern — color swatches for size, visual tiles for material, range sliders for price — does not come with free accessibility. Custom checkboxes require the role and aria-checked state. Multi-select filters need grouping with proper legend text. When a filter is applied and the product grid updates, a screen reader user needs to hear how many results remain.
The working implementation uses ARIA live regions on the results count, properly labeled controls with keyboard focus states, and a visible "clear all filters" option that can be tabbed to. When filters live inside an off-canvas panel on mobile, focus management becomes mandatory — focus has to move into the panel when it opens and back to the trigger when it closes. Without that, a keyboard user can open the filter panel and then be stranded outside it, unable to interact with the controls inside.
Variant Swatches Without Labels
The single most common product-page failure is color and size swatches implemented as divs with background colors and no text alternative. A sighted user sees a row of circles and picks navy. A screen reader user hears nothing, or hears "button" nine times in a row with no distinguishing information. The selected state is communicated only through a subtle border that has no announced equivalent.
The fix is mechanical once the problem is seen. Each swatch gets a text label either visually (preferred) or via aria-label. The selected state uses aria-pressed or a grouped radio pattern. The swatch group has a legend identifying what is being chosen ("Select color: Navy," "Select size: Medium"). Some platforms ship this correctly in newer themes; most installations still have legacy product templates carrying the older broken pattern forward. This is exactly the kind of issue a proper accessibility audit flags on the first pass.
Ecommerce accessibility failures concentrate in a predictable sequence: filter controls, variant swatches, cart update announcements, form field labels, and payment iframe inheritance. Testing the full purchase path with a screen reader catches what automated scanners miss entirely.
The Cart Update Problem
Adding a product to cart is usually an AJAX operation — the page does not reload, the cart count in the header updates, and a notification may slide in. For a sighted user this is obvious. For a screen reader user, silence. Nothing was announced. The user is left wondering whether the click registered, and often clicks again, producing duplicates.
The solution is an ARIA live region with polite or assertive politeness. The product title and "added to cart" confirmation are written into that region when the request completes, and assistive technology announces them. The same pattern applies to quantity updates, cart-line removals, and promo code application ("Code SUMMER20 applied. Your total is now $48.00"). Live regions are tiny to implement and almost entirely absent from stock ecommerce themes.
Checkout Forms: Where Most Money Is Lost
Checkout is the single highest-stakes accessibility surface on any ecommerce site, because failure at checkout is failure at the business objective. Every form field needs a persistent visible label, not a placeholder. Autocomplete attributes (autocomplete="given-name," "family-name," "email," "tel," "postal-code") have to be set so users of password managers and form-fill tools can complete the form in seconds instead of minutes. Validation errors have to be associated with their fields via aria-describedby, announced as they appear, and not just color-coded.
The address step is where patterns diverge. Country-specific field sets, dynamic state dropdowns that populate after the country changes, shipping options that update totals in real time — each transition has to announce what changed. The most overlooked piece is the guest-checkout path. Forcing account creation at checkout is a conversion killer for everyone, but it disproportionately penalizes users with cognitive disabilities or anyone managing multiple passwords with assistive tools. Offer guest checkout first and account creation as an opt-in at the end.
The Payment Iframe Trap
Most modern ecommerce sites embed payment via Stripe Elements, Braintree Hosted Fields, or a similar iframe-based solution. PCI compliance drives this — card data never touches the merchant's server — but it creates an accessibility boundary. The iframe is a separate document. The accessibility work done in the parent page does not automatically apply inside it. If the embed is misconfigured, keyboard focus can get trapped inside the iframe, or iframe errors can announce without context.
The major processors all offer accessible modes and documented ARIA patterns for their embedded inputs. The work is to configure them: pass field labels through the initialization options, style focus rings so they are visible at required contrast, test the full card-entry flow with a screen reader and keyboard-only. An embed that works for 95 percent of users and silently fails for the 5 percent using assistive technology is the kind of finding that shows up in litigation, because it is reproducible on every session.
Post-Purchase: The Part Nobody Tests
The confirmation page after purchase is usually an afterthought — a big check mark, a thank-you message, an order number, and a forwarded email receipt. Accessibility testing rarely reaches this far. Common failures include the order number being rendered as image or decorative text without a proper heading structure, so a screen reader user cannot find or repeat it, and dynamic tracking links that load after page render without announcing themselves.
The working pattern is a clear H1 confirmation ("Order placed"), a properly marked-up list of what was purchased, the order number in selectable text with a surrounding label, and any tracking information either present at render or announced via live region when it loads. The email receipt also deserves attention: many transactional email templates have image-only headers with no alt text and call-to-action buttons that are background images on divs. If the email fails a screen reader, the purchase experience fails at the last step a customer cares about.
Getting Compliance Into the Build Pipeline
One-time remediation is how most ecommerce sites come into compliance; staying in compliance is harder. New collections launch every month, promotional banners get added for every holiday, and every new feature is a potential new issue. A program that holds up over time combines automated testing in CI (axe-core tests running on every pull request, blocking merges on regressions), manual testing on the critical path (home, category, product, cart, checkout) before each release, and an annual manual audit against the current WCAG standard by external testers.
This is what a mature ADA website compliance program looks like in practice, and it scales. The marginal cost of each new product launch is low once the pipeline exists. The cost of skipping the pipeline — settlement expenses averaging $20,000 to $100,000 per filing, plus remediation — is several orders of magnitude higher. Proper ecommerce accessibility compliance is the least expensive path once the time horizon extends past the current quarter.
Is Your Store Audit-Ready?
We audit, remediate, and wire accessibility testing into the build pipeline — so every product launch ships without re-opening the compliance problem.
Get My Free Audit →