Shopify ADA Compliance: Why the Overlay Widget Is Not a Defence

An accessibility overlay will not make your store ADA compliant, and in the United States it will not keep a demand letter out of your inbox. The widget sits on top of the page and rewrites the DOM in the browser after load. The HTML you actually ship stays broken. Real Shopify ADA compliance is theme work: colour contrast that passes 4.5:1, a keyboard focus order that matches the visual order, every form input tied to a real label, ARIA on custom components like variant pickers and cart drawers, and alt text discipline across the product catalogue. None of that is glamorous. All of it holds up when someone tests your site with a screen reader instead of a scanner.

Is Shopify ADA compliant? The platform is not your storefront

Shopify as a platform does a reasonable amount of accessibility work. Checkout is theirs, the admin is theirs, and the reference themes ship with skip links, visible focus states and sensible landmark structure. That is where Shopify's responsibility stops.

What gets sued is the published storefront: your theme, your customisations, your apps, your images, your copy. A plaintiff's firm runs a scanner against your collection pages and your PDP, gets a list of failures, and files. Shopify is not named. You are. Nothing in Shopify's own compliance posture transfers to a store with a third-party mega menu, a quick-view modal that traps nobody's focus, and 4,000 product images with alt text auto-filled from the filename.

So the honest answer to "is Shopify ADA compliant" is: Shopify gives you a starting point that is better than most platforms and worse than done.

What the overlay actually does

Overlay products load a JavaScript bundle that scans the rendered page and patches it: guessing alt text with image recognition, injecting ARIA roles, adding a floating toolbar with high-contrast and large-text toggles. Some of it works. Automated fixes can handle missing lang attributes, some obvious landmark gaps, and a few link-name issues.

The problems start where the interesting failures live. An overlay cannot know that your size chart is a JPEG of a table and that the numbers inside it are invisible to everyone using a screen reader. It cannot tell that your "Choose options" button appears eleven times on a collection page with no distinguishing accessible name. It guesses alt text for a product image and gets "woman in a white shirt" when the customer needed to know it is the oatmeal colourway, not the ivory one. And it fires after page load, which means assistive tech that has already parsed the DOM is working from the broken version.

The practical objection from the people the law is meant to protect is blunter than any of this. Many screen reader users actively block overlays, because the injected ARIA fights their own software. A tool a user has to disable to use your site is not a remediation.

Why the widget is not a legal defence

Web accessibility suits in the US are filed under Title III of the ADA, and in California under the Unruh Act, which carries statutory damages with a $4,000 floor per violation. That floor is why California filings cluster. The Department of Justice's 2024 rulemaking for state and local government websites adopted WCAG 2.1 Level AA as the technical standard, and while that rule does not bind private retailers, it hardened AA as the benchmark courts and plaintiffs reference.

Serial filers scan in bulk. Their complaints are built from automated output plus a short manual pass, and the presence of a widget does not stop the scan from finding contrast failures and unlabelled inputs in the underlying markup. In January 2025 the Federal Trade Commission settled with accessiBe over how its automated product had been marketed, which is worth knowing if your compliance plan currently consists of a monthly subscription and a certificate badge in the footer.

We have watched US merchants settle these rather than fight, because defending costs more than the demand. The widget did not feature in the negotiation.

Dawn theme accessibility issues, specifically

Dawn is one of the better-built themes on the platform and it still fails AA in predictable places once a real brand touches it:

• Colour schemes. The theme editor lets you pick any foreground and background pair with no contrast warning. Muted grey secondary text on off-white is the single most common failure we find.
• Cart drawer focus. Opens fine. Closing it often drops focus back to the top of the document instead of the button that opened it, so a keyboard user has to tab through the whole header again.
• Predictive search. Results update visually but the live region announcement gets lost when merchants restyle or replace the component.
• Slideshows. Autoplay with a pause control satisfies 2.2.2 only if the control is reachable and labelled. Swap in an app-based slider and that usually goes.
• Variant pickers. Dawn's native radio inputs are accessible. Third-party colour swatch apps frequently render div elements with click handlers and no role, name or state.
• Quick view and app modals. No focus trap, no escape-to-close, no return focus.

Every one of those is a theme-level fix measured in hours, not a subscription.

A WCAG 2.1 AA checklist for Shopify that matches how stores actually break

Ignore the 50-criterion master list for a first pass. This is where Shopify storefronts fail, roughly in order of how often we find it:

1. 1.4.3 Contrast. 4.5:1 for body text, 3:1 for text at 24px or 18.7px bold. Check sale prices, placeholder text, disabled buttons, badge labels and anything over a lifestyle image.
2. 1.4.11 Non-text contrast. Input borders, focus rings and icon buttons need 3:1 against their background. Thin 1px light-grey field borders fail constantly.
3. 2.4.7 Focus visible. Someone removed the outline in CSS to make the buttons look cleaner. Find it and put it back.
4. 2.1.1 and 2.1.2 Keyboard. Tab through the entire purchase path with the mouse unplugged: header nav, filters, swatch selection, add to cart, drawer, checkout button. Anything you cannot reach or cannot escape is a filing.
5. 3.3.2 Labels. Newsletter fields with placeholder-only labels, quantity inputs, contact forms, and the search field in the header.
6. 4.1.2 Name, role, value. Accordions, tabs, filter chips, swatches, anything built from divs.
7. 4.1.3 Status messages. "Added to cart" and filtered result counts need an aria-live region or they never get announced.
8. 1.4.10 Reflow. 320px width, no horizontal scroll. Sticky bars and size-chart tables break this.
9. 1.4.5 Images of text. Size charts, ingredient panels and promo banners with the offer baked into the JPEG.
10. 2.5.3 Label in name. A button that reads "Add to cart" with aria-label="ATC" breaks voice control users.

Here is the contrast point with real numbers, because "improve your contrast" is useless advice. A sale price in the common Material red #E53935 on a white background gives a contrast ratio of about 4.2:1. That fails AA for body-size text. Darken it to #C62828 and you get roughly 5.6:1, which passes, and on a product card almost nobody will notice the difference. That is the entire fix: one hex value in one schema setting. Run your palette through a contrast checker before you argue with your designer about it.

Alt text best practice when you have thousands of SKUs

Alt text is where merchants either do nothing or do too much. Both are failures.

The rule that scales: alt text describes what the image adds that the page text does not. If the H1 already says "Ribbed Cotton Crew Neck — Oatmeal", the hero shot does not need to repeat it. It needs to say what a sighted shopper gets from looking: "Model wearing the crew neck tucked into wide-leg jeans, showing mid-hip length". The fabric close-up says "Close-up of the ribbed knit texture". The flat-lay says "Front view, laid flat". Four images, four different strings, none of them starting with "image of".

Other things we enforce on catalogue work:

• Purely decorative images get alt="", not a description. Empty alt is a correct answer, not a missing one.
• Never keyword-stuff. It reads as spam to a screen reader user and does nothing for rankings.
• Size charts, ingredient lists and care instructions belong in HTML, not in a PNG. This is the fix that most often gets pushed to "phase two" and most often appears in a complaint.
• Bulk imports fill the alt field with the filename. Audit for anything matching a SKU pattern or ending in .jpg and clear it.
• Payment icons in the footer, trust badges and review stars all need either a real name or an empty alt. Star ratings rendered as five separate images with alt="star" produce "star star star star star" and tell nobody the score.

Is a Shopify accessibility app ever worth it?

Sometimes, for one job: monitoring. An automated scanner that crawls your templates weekly and flags regressions after a theme update or a new app install has genuine value, because accessibility decays. You fix the contrast in March, marketing adds a festive banner in November, and the ratio is back to 3:1 on your highest-traffic page of the year.

What you should not buy is anything sold as compliance-in-a-tag. If the pitch mentions a certificate, a litigation guarantee or AI that fixes your site automatically, treat the guarantee as marketing rather than indemnity and read what it actually covers. Free tooling gets you most of the scanning value anyway: Lighthouse is built into Chrome, and axe DevTools catches roughly a third of WCAG issues automatically. The other two thirds need a person with a keyboard and a screen reader.

What a Shopify accessibility audit costs

A useful manual audit covers your template types rather than your page count, which is why a 12,000-SKU store does not cost more to audit than a 200-SKU one. Home, collection, product, cart, search, blog, account, and any custom landing page built outside the theme. That is typically 20 to 40 hours of testing: automated scan, then manual keyboard pass, then NVDA or VoiceOver on the full purchase path, then a documented issue list mapped to WCAG success criteria with severity.

Remediation on a Dawn-based theme usually lands between 30 and 60 hours, most of it in custom sections and app-injected components rather than the base theme. Headless builds cost more because the component library has to be fixed at source. Add catalogue alt text as a separate line item priced per thousand images, since it is content work and someone on your team may do it cheaper than an agency will.

Compare that to the cost of one settlement plus the remediation you will be ordered to do anyway. The arithmetic is not close.

Where to start this week

Unplug your mouse. Open your own store. Try to buy something. Most US merchants find their first blocking failure within ninety seconds, usually in the header navigation or the cart drawer, and that single test will tell you more than any dashboard score.

Then fix contrast, because it is the cheapest points on the board and the most commonly cited failure. Then labels. Then focus order. Do it before your Black Friday landing pages go into the theme, not after, because November is when your traffic and your exposure both peak.

If you want an outside read on where your theme stands, our team runs a free store audit that includes an accessibility pass alongside speed and conversion. For remediation work across US storefronts, see how we work with US-based brands, or talk to us about a dedicated Shopify developer if the fixes are spread across a year of accumulated custom sections.