Shopify Accessibility and ADA Compliance: Risk, Cost and What to Fix First

Most Shopify merchants encounter accessibility in one of two ways. Either nobody mentions it until a demand letter arrives, or someone sells them a widget that promises compliance for a monthly fee and the box gets ticked.

The widget is the part worth questioning immediately. Accessibility overlays — the scripts that add a little accessibility icon and a menu of contrast and font-size toggles — have been criticised by accessibility practitioners and disability advocates for years. The argument is straightforward: they sit on top of an inaccessible site and don't fix the underlying markup, so a screen reader user still hits the same barriers. Sites running overlays have still received demand letters.

Which means a merchant paying for one may be carrying both the cost and the risk, while believing they've handled it.

The genuine work is less exciting and more finite than people expect. Keyboard navigation. Colour contrast. Form labels. Alt text. Focus indicators. Most of it lives in your theme, most of it is fixable by a competent developer, and — the part nobody mentions — most of it also makes the site better for customers who aren't disabled at all.

This is a practical guide, not legal advice. Accessibility law varies significantly by jurisdiction and continues to develop. If you have received a demand letter or believe you have exposure, speak to a qualified lawyer in your jurisdiction rather than acting on any article.

There isn't a single global rule, but the standard everything points at is consistent.

WCAG is the reference standard. The Web Content Accessibility Guidelines, published by the W3C, define what accessible means in testable terms. Level AA of WCAG 2.1 is the level most commonly referenced in legal contexts, procurement requirements and settlements. WCAG 2.2 followed with additional criteria. If someone asks what you're conforming to, the answer people expect is WCAG 2.1 AA or later.

United States. The Americans with Disabilities Act has been applied to commercial websites through Title III litigation, and lawsuits and demand letters against ecommerce sites are filed in large numbers each year. The ADA itself doesn't specify WCAG by name, which is part of why this area is litigated rather than simply regulated — courts and settlements have repeatedly used WCAG as the practical yardstick. Some states have their own statutes with their own exposure.

European Union. The European Accessibility Act extends accessibility requirements to a range of services including many ecommerce operations. If you sell into the EU, this applies to you regardless of where you're based — the same reasoning that makes GDPR your problem, covered in the compliance work under privacy and data compliance.

Canada, UK and elsewhere. Ontario's AODA sets its own requirements. The UK's Equality Act creates obligations for service providers. Australia, and others, have their own frameworks.

The practical upshot: conform to WCAG 2.1 AA and you are substantially addressing most of these at once. Chasing each jurisdiction separately is how this becomes overwhelming; the standard underneath them is broadly the same.

The pattern is worth understanding because it shapes the sensible response.

Most claims begin as a demand letter rather than a filed lawsuit — a letter alleging your site is inaccessible and proposing settlement. They frequently arrive in volume, generated by scanning many sites for common automated failures rather than by a customer who genuinely tried to shop with you.

That has two implications, and they point in the same direction.

First, the failures being scanned for are the easy ones. Missing alt text, contrast failures, unlabelled form fields, missing page language. These are exactly what automated tools detect, and exactly what a competent developer can fix. Being an easy target is largely avoidable.

Second, doing the work genuinely reduces exposure. Not eliminates — nobody can promise that, and any vendor who does is overselling. But a site that passes automated checks and has a documented remediation process is a much less attractive target than one failing on the obvious things.

Keep a record. An audit report, a remediation plan with dates, and an accessibility statement on your site demonstrating what you conform to and how someone can report a problem. Documented good-faith effort matters, and it costs almost nothing to maintain once the work is done.

One thing worth saying plainly: framing this purely as legal risk is a bit grim. Roughly one in five people has a disability. Some of them are trying to buy from you and can't.

Most accessibility failures on Shopify come from the theme, not from Shopify itself. Themes vary enormously — some are built carefully, plenty are not, and "accessible" in a theme's marketing copy is not an audit.

Colour contrast. The single most common failure. Light grey text on white, pale text over hero images, low-contrast buttons and form placeholders. Designers pick it because it looks refined; a large share of users can't read it.

Keyboard navigation. Try it: unplug your mouse and buy something from your own store. Can you reach every link and button with Tab? Open and close the cart drawer? Escape a modal? Get through checkout? Keyboard traps — where focus enters a component and can't leave — are common in mega menus, drawers and popups.

Missing focus indicators. Themes frequently remove the browser's default focus outline because it looks untidy. Without it, a keyboard user has no idea where they are on the page.

Alt text. Missing on product images, or filled with keyword strings rather than descriptions. Decorative images should be marked as decorative rather than described. This overlaps directly with product page SEO, though the accessibility standard is higher than the SEO one.

Form labels. Placeholder text is not a label. Fields relying on placeholders alone leave screen reader users with no idea what to enter — and the placeholder disappears when they start typing, which is a usability problem for everyone.

Heading structure. Headings used for visual size rather than document structure. Screen reader users navigate by heading, so a page with no logical hierarchy is genuinely hard to use.

Popups, modals and app-injected content. Third-party apps are a major secondary source — review widgets, popups, chat launchers and upsell modals often ship with poor accessibility and inject themselves into your storefront. You can have a well-built theme and a badly-behaved stack, which is another cost of app bloat, covered in apps slowing your store.

Because this deserves to be direct rather than hedged: an overlay is not a substitute for an accessible site.

Overlay products inject JavaScript that adds an accessibility menu and attempts automated remediation — guessing at alt text, adjusting contrast, adding ARIA attributes on the fly. The pitch is compliance without touching your code.

Why practitioners object: the underlying markup stays broken, so the barriers remain for people using their own assistive technology. Automated fixes guess, and guesses are often wrong — an incorrect alt description can be worse than none. Overlays can also interfere with screen readers users have already configured. Disability advocacy organisations have been vocal about this, and many accessibility professionals have publicly opposed these products.

And legally: sites running overlays have still received demand letters and faced claims. Whatever a vendor's marketing implies, an overlay is not established protection.

What to do if you have one: don't necessarily rip it out this afternoon, but stop treating it as your accessibility programme. Get a real audit, find out where you actually stand, and fix the underlying issues. Then decide whether the subscription is buying you anything.

The narrow honest case for them: some offer genuine user-preference features — text resizing, reading guides — that some users like. That's a feature, not compliance, and it should be priced and evaluated as one.

You can do the first three yourself this week.

1. Run an automated scan. Free browser tools and the accessibility audit built into Chrome's developer tools will surface contrast failures, missing alt text, unlabelled fields and structural problems in minutes. Automated tools catch maybe a third of real issues, but that third is precisely what mass-generated demand letters target.

2. Do the keyboard test. Put the mouse away and complete a purchase. Navigate the menu, filter a collection, open the cart, get through checkout. Every place you get stuck is a real barrier for real users.

3. Check your theme and apps. Ask your theme developer what accessibility work they've done and against which standard. Identify which apps inject content into the storefront, because those are your likely secondary failures.

4. Get a manual audit. Automated tools can't evaluate whether alt text is meaningful, whether focus order is logical, or whether a screen reader experience makes sense. A manual audit against WCAG 2.1 AA — ideally including testing with assistive technology — is what tells you where you actually stand. This is the point where you need accessibility and ADA compliance specialists.

5. Remediate in priority order. Fix checkout and the purchase path first — that's where a barrier costs a customer and creates the clearest claim. Then product and collection pages. Then everything else.

6. Publish an accessibility statement and keep testing. State what you conform to, acknowledge known limitations, and give people a way to report problems. Then re-test after theme changes, app installs and redesigns, because accessibility regresses quietly.

Costs vary by store size, theme quality and how much has been customised, so treat these as shape rather than quotes.

What drives cost up: a heavily customised theme, a large app stack injecting content, custom checkout work, and a store that has never had any accessibility attention. What brings it down: a well-built modern theme, a lean app stack, and catching issues during a redesign rather than retrofitting afterwards.

The timing argument. If a redesign or theme change is on your roadmap, build accessibility into that project. Retrofitting later routinely costs several times more than doing it as part of the build, and this is the single most useful piece of budget advice in the article. If you're choosing a theme now, ask about accessibility before you buy — best Shopify themes covers the wider selection question.

Worth stating because it changes how you should budget this.

Almost everything on the accessibility list improves the store for everyone. Better contrast helps anyone shopping outdoors on a phone. Proper form labels reduce checkout errors across the board. Clear focus indicators help keyboard-preferring power users. Logical heading structure helps every visitor scan a page, and helps search engines and AI systems parse it — the same structural clarity that makes content extractable, covered in AI search optimization.

Descriptive alt text serves screen reader users, image search, and anyone on a slow connection.

There's meaningful overlap with conversion work generally: forms that are hard to complete, navigation that traps people, and text that's hard to read are conversion problems before they're compliance problems. If you're already planning CRO work, accessibility findings belong in the same backlog rather than a separate one.

So the budget framing that actually holds up isn't "legal insurance." It's usability work with a compliance benefit attached — which is a much easier case to make internally, and a more honest description of what you're buying.

Accessibility remediation is specialist work, and general Shopify development experience doesn't automatically cover it.

When to hire: you've received a demand letter, in which case speak to a lawyer first and a specialist immediately after; you're planning a redesign and want it built accessibly from the start, which is the cheapest possible moment; you sell into the EU and want to understand your position; or your automated scan surfaced enough to know you need a proper assessment.

How to vet: ask which standard they audit against and whether they test with assistive technology or only automated tools. Ask for a sample audit report. Ask whether they remediate or only assess, since those are different engagements. And be sceptical of anyone guaranteeing you can't be sued — nobody can promise that, and the promise itself tells you something.

Who does what: accessibility and ADA compliance experts for audits and remediation, theme customization experts where fixes are theme-level, and UX/UI design experts when a redesign is the vehicle. A broader technical audit can cover accessibility alongside performance and code quality if you'd rather assess everything at once.

Design and UX specialists by market: United States, United Kingdom, Australia, Canada, Germany.

Run a free automated scan today and try buying from your own store without a mouse. Those two things take an hour and will tell you whether you have a small problem or a real one.

If you're running an overlay, stop counting it as your accessibility programme and find out where you actually stand. If a redesign is coming, build this into it — that's the cheapest version of this work you will ever be offered.

For a proper audit against WCAG 2.1 AA or theme-level remediation, browse accessibility and ADA compliance experts. Free matching, verified experience, no commissions.

Related guides on design, compliance and store quality:

• Accessibility & ADA Compliance Experts — audits and remediation against WCAG
• UX/UI Design Experts — building accessibility in during a redesign
• Privacy & GDPR Compliance Experts — the other EU obligation that follows where you sell
• Shopify CRO — why accessibility findings belong in your conversion backlog
• Best Shopify Themes — ask about accessibility before you buy
• Shopify Apps Slowing Your Store? — app-injected content as a secondary failure source
• Shopify Product Page SEO — alt text where SEO and accessibility overlap