Shoppers who can't check out don't complain. They leave.
Most store barriers sit between the product page and the receipt: a size picker that ignores the keyboard, a cart drawer that opens in silence, a payment step a screen reader can't finish. We test those journeys first, fix them in your theme, and keep third-party scripts from undoing the work.
The home page is rarely where a sale is lost
Automated scans start at the home page because that is where the URL list starts. Shoppers don't stop there. They search, filter, pick a size, open the cart, enter an address, and pay, and each of those steps is usually a different component, often built by a different team or app vendor.
That is where we spend our time. A filter panel that refreshes the product grid without telling a screen reader anything changed. A color swatch that is a styled div with no role and no selected state. A quantity stepper whose buttons are smaller than a fingertip. A delivery-date picker that traps keyboard focus one step before payment. None of these shows up as a red number on a dashboard, and every one of them ends the visit for someone.
Journeys we test first
We start with the path from search to receipt, on a phone and a desktop, then widen to sign-in, returns, and store-locator pages.
| Component | What usually breaks | Who is blocked | WCAG 2.2 criteria |
|---|---|---|---|
| Search and suggestions | The suggestion list isn't announced, arrow keys don't move through it, and the result count never reaches a screen reader | Screen reader and keyboard users | SC 4.1.2, SC 4.1.3 |
| Filters and sorting | Checking a filter reloads the grid and drops focus to the top of the page | Keyboard, screen reader, and switch users | SC 2.4.3, SC 4.1.3 |
| Variant picker | Swatches have no name, role, or selected state; sold-out sizes are shown by color alone | Screen reader users; people with low vision or color blindness | SC 4.1.2, SC 1.4.1 |
| Carousels and image galleries | Slides advance with no pause control; thumbnails lack alt text; zoom works only on mouse hover | People with attention-related disabilities; screen reader and keyboard users | SC 2.2.2, SC 1.1.1, SC 2.1.1 |
| Cart drawer | Opens without moving focus or announcing itself; the close button has no name | Screen reader and keyboard users | SC 2.4.3, SC 4.1.2 |
| Checkout and payment | Errors not tied to fields; date pickers that trap focus; quantity steppers smaller than 24 by 24 CSS pixels | Everyone using assistive technology; people with tremor or limited dexterity | SC 3.3.1, SC 2.1.2, SC 2.5.8 |
Retail is where most digital accessibility claims land
The first two figures come from one vendor's year-end report, which counts federal and state filings over websites, apps, and video.
of 2025 digital accessibility lawsuits targeted e-commerce businesses
UsableNet, 2025 Year-End Digital Accessibility Lawsuit Reportdigital accessibility lawsuits were filed in U.S. federal and state courts in 2025
UsableNet, 2025 Year-End Digital Accessibility Lawsuit Reportis the date from which EU member states must apply the European Accessibility Act (Directive (EU) 2019/882), which covers products and services, including e-commerce, on the EU market
Directive (EU) 2019/882 of 17 April 2019 (European Accessibility Act), Article 31(2), EUR-LexTracking pixels, consent banners, and the speed of your product page
A typical product page loads scripts from analytics, advertising, reviews, chat, personalization, and testing vendors. Each one adds main-thread work, which slows the response on the very pages where a shopper taps Add to cart. A good Interaction to Next Paint is 200 milliseconds or less at the 75th percentile, and when a store misses it, third-party code is the first place we look.
Scripts also raise privacy questions. Some tags fire before a visitor answers the consent banner, or keep firing after they decline. Some send page URLs or form values to an ad platform. Our Tag & Script Governance audit inventories every script, measures its cost in milliseconds, records when it fires relative to consent, and names an owner for each. We report what the code does; whether a particular data flow creates legal exposure is a question for your privacy counsel.
The consent banner is itself a frequent accessibility failure: a dialog that covers the page visually but not for screen readers, a Reject link styled at low contrast, or a banner a keyboard can't dismiss. We test it like any other component.
Selling to customers in the European Union
The European Accessibility Act has applied since June 28, 2025, and it covers e-commerce services offered to consumers in EU member states. A US retailer that sells to EU customers can fall within its scope without having an EU office. Very small service businesses, called microenterprises, are exempt from the service requirements, and some transitional periods apply.
Each member state enforces the act through its own national law, and the harmonized European standard, EN 301 549, maps to WCAG for web content. In practice, a WCAG 2.2 AA program for your storefront covers most of the technical ground. The act also expects you to explain how your service meets the requirements, which most sellers do with an accessibility statement. Ask your counsel whether and how the act applies to your EU sales, and see our article on the EAA one year in for what US sellers have run into so far.
Fixes that live in your theme, not on top of it
We work in the platform you already run, so the fix survives the next theme update and app install.
Shopify
Theme sections, snippets, and Liquid templates, plus the app embeds that inject cart drawers, reviews, and upsells. When an app is the source, we document the barrier for its developer and work around it in the theme where we can.
BigCommerce
Stencil theme templates and components, faceted search, and checkout customizations, delivered as reviewed changes to your theme repository.
Salesforce Commerce Cloud
Storefront cartridges or headless components, tested in your sandbox and handed back as pull requests your team merges on its own release schedule.
Adobe Commerce
Theme layouts, templates, and front-end modules, with close attention to checkout UI components and third-party payment extensions.
Headless and custom storefronts
React, Vue, or server-rendered front ends on a commerce API. We fix the shared components in your design system so one change clears every page that uses them.
What store owners ask us
Our platform says its themes are accessible. Isn't that enough?
A theme can start in good shape and drift. Every app you install, custom section you add, and script your marketing team loads changes the page. We test your store as it is today, apps included, and tell you which barriers come from the theme, which from apps, and which from your own changes.
Can you test checkout without placing real orders?
Yes. Depending on your platform, we use a staging store, a test payment gateway, or a discount code that zeroes the total. We never enter real customer data, and we agree on the rules with your team before touching anything in production.
We received a demand letter. Where do we start?
Send it to your attorney first. Our Demand-Letter Technical Support then reviews every barrier the letter cites within 72 hours and builds an evidence pack your attorney can use. We don't give legal advice, but we can tell your counsel exactly what the code does.
Will accessibility fixes slow down our store?
Usually the opposite. Accessible fixes often replace heavy custom widgets with native HTML elements, which are lighter and respond faster. When a fix does add code, we measure its effect on Core Web Vitals before we hand it over.
Keep reading
Tell us what your website needs to do.
Send a link and a sentence about your deadline. You will hear back from a person within one business day, usually with a short list of questions and a proposed scope.