Search the Shopify App Store for "accessibility" and you will get pages of results. Widgets that promise one-click compliance. Toolbars with font-size sliders and a contrast switch. Badges that say "ADA compliant" right in the listing thumbnail. It looks like a solved problem, priced at nine dollars a month.
Then a merchant installs one, checks the box in their head, and moves on. Nobody goes back to verify the claim, because the app is sitting there in the admin panel, visibly doing something. The install itself starts to feel like the compliance work.
That gap, between "I installed an app called accessibility" and "my store actually meets WCAG," is where a lot of Shopify merchants are quietly exposed. Not because they were careless, but because nothing in the App Store listing tells them where that gap is.
The Stat: Deque's own published research finds automated scanning alone catches roughly 57.38% of WCAG issues - a limit that applies to an installed app just as much as to a manual scan. (Source: Deque Systems)
What these apps are actually built to do
Strip away the marketing copy and Shopify accessibility apps fall into a small number of real technical categories. Understanding which category an app belongs to tells you almost everything about what it can and cannot fix.
Overlay and widget apps. These inject a floating panel, usually a script tag added to your theme, that lets a visitor toggle font size, line spacing, contrast, or a "dyslexia friendly" font. Some attempt to rewrite the page's accessibility tree on the fly, adding ARIA attributes or alt text guesses through automated pattern matching. This category runs entirely client-side, after your theme has already rendered.
Automated scanning and reporting apps. These crawl your storefront and generate a list of detected issues, missing alt attributes, low contrast ratios, unlabeled form fields, similar to what a browser extension like axe DevTools would surface. Some plug directly into the open-source axe-core engine that powers a large share of the automated testing market. They are genuinely useful as a first pass. They are not a remediation tool by themselves.
Theme and code-assist apps. A smaller category that helps a developer find and fix specific markup issues inside the theme's Liquid templates, things like heading structure, landmark regions, or focus order. These get closer to a real fix because they touch the actual HTML, but they still depend on a person applying and verifying the changes.
Nowhere in that list is a category that can independently guarantee legal conformance. That is not a knock on any specific product. It is a structural limit of what software bolted onto a storefront can verify about itself.
Think about what each category is actually looking at. An overlay script runs in the browser after your theme has already rendered, so it can only patch what it can detect in the live DOM at that moment. It has no visibility into how your product data was structured upstream, no way to know whether an image's alt text was ever meant to be decorative or descriptive, and no ability to fix a broken heading order without risking a different kind of breakage. A scanning app is more honest about its limits by design, it hands you a list rather than a fix, but that list is only as good as the patterns its engine knows to look for. Novel components, custom checkout apps, and third-party embeds from other tools in your stack routinely fall outside what any of these categories can see at all.
Why the App Store listing does not say this
Shopify's App Store review process checks that an app functions as described, meets performance and security requirements, and does not break the storefront. It does not certify that an app labeled "accessibility" actually achieves WCAG conformance for every store that installs it, because that outcome depends on the merchant's own theme, content, and third-party embeds, not just the app.
That leaves a wide-open lane for confident marketing. A listing can legitimately say "adds accessibility features" without ever specifying which WCAG success criteria those features address, at what conformance level (A, AA, or AAA), or how that claim was tested. A five-star rating tells you merchants are happy with the interface. It tells you nothing about whether a screen reader user can complete checkout.
This is the same pattern our team has documented in the broader overlay market, unrelated to any single platform: see AI Overlays, We Tested 5, All Failed WCAG for what happens when an automated, script-injected fix is checked against a real assistive technology rather than a demo video. The Shopify App Store version of this problem is narrower in scope but identical in shape. An app category name is not a test result.
The checklist: what to actually ask before you trust an app's claim
Before treating any Shopify accessibility app as your compliance answer, get specific.
- What does it actually change? Client-side overlay, server-rendered theme edit, or a report you have to act on yourself? Each has a completely different relationship to your actual HTML.
- What standard, at what level? "Accessible" is not a standard. WCAG 2.2 AA is. Ask the vendor to name it directly.
- Who tested it, and how? Automated scan only, or automated plus manual testing with a keyboard and a screen reader like NVDA or VoiceOver? The two produce very different confidence levels, and neither one alone is complete.
- Does it touch checkout and cart? Many storefront apps only run on product and collection pages. Shopify's hosted checkout has its own constraints, and a widget that never loads there leaves your highest-stakes flow untouched.
- What happens when you uninstall it? If every accessibility gain disappears the moment you remove an app, none of the underlying markup was actually fixed. That is a rented fix, not an owned one.
- Can it show you a written accessibility statement? A dated, specific statement, distinct from marketing copy, is a far stronger signal than a badge graphic.
None of this means skip the automated tools. A scanning app or the axe-core engine behind it is a legitimate, fast way to catch a real share of issues, roughly the same proportion Deque's own research puts at 57.38% of WCAG issues, as cited above. The mistake is stopping there and calling the remaining gap solved.
Where this fits next to the rest of your Shopify decision
If you are weighing Shopify against another platform on accessibility grounds generally, that is a separate and broader question, one we cover in Shopify vs WooCommerce: Which Is Actually More Accessible?. This piece is narrower on purpose: regardless of which platform you run, the app ecosystem layer sitting on top of it needs its own scrutiny, separate from your theme's baseline markup and separate from the platform-level comparison.
The honest position is that a good app can be part of a real accessibility program. It is rarely the whole program. Combining automated tooling with actual manual testing, a documented remediation plan, and a real accessibility statement is what closes the gap the App Store listing never mentions. If you want a clear picture of where your specific storefront and checkout stand today, our team can walk through it with you at wcag.world/solutions/shopify.
The W3C's own guidance on accessibility statements makes the same point from the standards side: a specific, honest, dated statement about what has been tested and how carries far more weight than a generic badge, on Shopify or anywhere else.
Talk to a person about it
If you have already installed one of these apps and want to know exactly what it does and does not cover for your store, reach our team at experts@wcag.world. We can walk through your theme, your checkout, and your current app stack against real WCAG criteria, not just a listing description, starting at wcag.world/solutions/shopify.