Search the Shopify App Store for "accessibility" and you get a long list of apps that all promise the same outcome: a more accessible store, fewer legal worries, a compliance badge. The promises sound interchangeable. They are not. The single most important difference between accessibility apps is whether the app changes your store's source code or only changes what the browser shows at runtime. That one distinction decides whether the app helps you with the thing courts and auditors actually examine, or whether it leaves the underlying problem in place. This guide explains the categories, the questions to ask, and how to read past the marketing so you can choose the best Shopify accessibility app for your store rather than the loudest one.
The two categories every accessibility app falls into
Almost every accessibility app on the App Store is one of two things, even when the listing does not say so plainly.
Overlays are JavaScript widgets. You install the app, it adds a script to your theme, and a button appears on your storefront. A visitor clicks it and a panel opens with toggles like "high contrast", "bigger text", and "pause animations". The widget injects CSS and sometimes ARIA attributes into the page in the browser, after the page has loaded. It does not change the HTML your Shopify theme actually sends to the visitor. We covered this category in depth in our piece on why accessibility overlays do not protect against ADA lawsuits.
Code-level remediation tools scan your storefront, identify barriers, and help you change the actual theme files: the Liquid templates, the CSS, the alt text on your products. The fix lives in your source code. It is present from the first millisecond of page load, it survives a reload, it works even if a script fails, and it is visible to anyone who reads the page source.
The reason this matters is not philosophical. The HTML your theme ships is what a screen reader reads, what an automated scanner grades, and what a plaintiff's attorney inspects. An overlay does not touch that HTML. A code fix does.
Why the source code is what gets assessed
When a US court evaluates a website accessibility claim, it looks at whether the site is usable, not at which vendor logos appear in the footer. In Robles v. Domino's Pizza, 913 F.3d 898 (9th Cir. 2019), the 9th Circuit held that a website tied to a physical place of public accommodation falls under the ADA, and that a blind user being unable to complete an order was the relevant fact. The remediation tools deployed did not change that analysis. The question was access, delivered by the page itself.
The clearest signal that overlays have been oversold came in January 2025, when the US Federal Trade Commission settled with accessiBe, the largest overlay vendor. The settlement required a 1 million USD payment and prohibited accessiBe from claiming that its product alone makes a website compliant with the ADA or WCAG. That is the most authoritative federal record we have that an overlay button is not the same as an accessible site.
On the EU side, the European Accessibility Act (Directive (EU) 2019/882) pushes many online stores toward the harmonised standard EN 301 549, which references the WCAG success criteria. EN 301 549 is assessed against the delivered experience and the underlying markup, not against the presence of a widget. If you sell into the EU, see our walkthrough of EAA compliance for Shopify Plus.
None of these frameworks reward you for installing a script. They reward a page that works.
Eight questions to ask before you install any accessibility app
Use these to cut through the listing copy. The answers tell you which category the app is in and how much real work it will do.
- Does it change my theme code or inject a runtime script? This is the first and most important question. If the app only adds a widget, it is an overlay. If it edits Liquid and CSS, it is remediation. If the listing is vague, that vagueness is usually the answer.
- Can I preview a fix before it goes live? A tool that edits your theme should show you the exact change first. You should be able to read the diff and decide. Blind, automatic edits to a live theme are a risk to your design and your revenue.
- Does it map findings to specific WCAG success criteria? Real remediation cites the criterion by number and level, for example WCAG 2.1 success criterion 1.4.3 (contrast minimum, level AA) or 1.1.1 (non-text content, level A). Vague "accessibility score" numbers with no criteria behind them are hard to act on and hard to verify.
- Does it claim to make me "compliant" or "ADA compliant"? Treat any app that guarantees legal compliance with caution. No app makes a store legally compliant on its own. Compliance depends on your full content, your apps, your operations, and in some cases legal review. The FTC settlement above is exactly about this overclaim.
- What happens on a slow connection or if the script fails? An overlay only helps after its script loads and the visitor finds the button. A code fix is in the page before any script runs. Ask what the experience is in the gap.
- Will it work with a screen reader out of the box? The user group most often involved in litigation relies on screen readers, and many switch off custom widgets. A fix in the markup helps them by default. A widget they never open does not.
- Can I see and keep the changes? If the app left tomorrow, would your accessibility improvements stay? Code changes you committed to your theme stay. A widget that vanishes when you uninstall the app takes its "fixes" with it.
- What does it cost as you grow, and what is free? Many tools offer a free tier to start and paid plans for more pages or features. Check the App Store listing for current pricing rather than trusting a number in a blog post, and confirm what is included free before you commit.