How to Test Your Shopify Store for Accessibility: a Free Scan and What It Finds
A Shopify accessibility checker test tool, step by step: how a free scan works, the WCAG issues it surfaces, and how to read the results without overclaiming compliance.
By Radoslaw Fedorczuk8 min read
Testing your Shopify store for accessibility starts with a scan of your live, rendered HTML against the WCAG 2.2 success criteria, because that rendered HTML is what screen reader users, automated audits, and plaintiffs' attorneys actually see. A free homepage scan is the fastest way to get a baseline: it tells you which Level A and AA criteria your theme is failing right now, on the specific pages a buyer hits first. This article walks through how that test works, what it can and cannot find, and how to read the results without mistaking a scan for a compliance certificate.
A Shopify theme is written in Liquid, a server-side templating language. The server compiles your Liquid and ships plain HTML and CSS to the browser. That output is the surface every accessibility test should examine, for one reason: it is the same surface a screen reader parses and an auditor reviews. A good test reads the delivered markup and checks it against named WCAG criteria.
This is also why a scan is a different category of tool from an accessibility overlay. Overlays are runtime JavaScript widgets that toggle font size or contrast in the browser after the page loads. They do not change the underlying source HTML, which is the thing courts and audits assess. The US Federal Trade Commission made the gap explicit in its January 2025 settlement with accessiBe, the largest overlay vendor: the settlement required a 1 million USD payment and prohibited accessiBe from claiming its product alone makes a site compliant with the ADA or WCAG. A scan does not pretend to fix anything by loading a script. It reads your real markup and reports what fails. We cover the legal background in why overlays do not protect against ADA lawsuits.
The AccessifyAI scanner fetches your storefront the way a browser does, renders it, and runs each element against the WCAG 2.2 Level A and AA success criteria. The checks that surface most often on Shopify storefronts cluster into a handful of categories:
Images without alt text (WCAG 1.1.1). Product images, collection tiles, and banner images that ship with no alt attribute, or with a filename as the alt value. Screen reader users hear nothing useful.
Color contrast below threshold (WCAG 1.4.3, 1.4.11). Body text, button labels on hover, placeholder text, and focus outlines that fall under the 4.5:1 ratio for normal text or 3:1 for large text and non-text UI.
Form fields without labels (WCAG 1.3.1, 4.1.2). Newsletter signups, search boxes, and contact forms where the input has no programmatic label.
Broken heading structure (WCAG 1.3.1). Pages that jump from an H1 to an H4, or that style a <div> to look like a heading without using a heading tag.
Missing or invisible focus indicators (WCAG 2.4.7). Keyboard users cannot see where they are because a global outline: none was never replaced.
Links and buttons without an accessible name (WCAG 2.4.4, 4.1.2). Icon-only buttons (cart, search, menu) that expose no text to assistive technology.
The scan returns each finding mapped to its specific success criterion and conformance level, so you are not reading a vague score. You are reading a list of named, checkable problems.
This is the part most "compliance checker" marketing skips, so be precise about it. Automated testing reliably catches issues that are machine-detectable: a missing alt attribute, a contrast ratio under threshold, an input with no associated label, a heading level skipped in the source. These are real failures and worth fixing first because they are unambiguous.
Automated testing cannot judge issues that require human reasoning. A scanner can confirm an image has alt text; it cannot confirm the alt text is accurate or meaningful. It can flag a heading; it cannot decide whether the heading describes the section. It cannot evaluate whether your checkout flow makes sense to someone using a screen reader, or whether a custom date picker is operable by keyboard end to end. The W3C and every serious testing methodology treat automated scans as a first pass that catches a meaningful subset of issues, not the whole of WCAG. Any tool that claims a single automated scan makes you "fully compliant" is overstating what the technology does, the same overstatement the FTC penalized.
So read your scan results as: here are the machine-detectable barriers on this page, fix these, then plan manual testing for the rest. A scan narrows the work. It does not end it.
When the scan finishes, work through the findings in this order:
Group by success criterion, not by element. If forty images are missing alt text, that is one pattern to fix in one place, not forty separate tasks.
Sort by conformance level. Level A failures are the most basic barriers; address them before Level AA. Note that AAA criteria, where you see them, are not part of the legal floor that frameworks like the ADA and the EU's harmonised norm EN 301 549 reference, so do not let AAA items crowd out A and AA work.
Check whether the issue lives in the theme or an app. A contrast problem in your brand color token is a theme fix. A focus trap inside a third-party popup app is an app fix, and sometimes the only honest answer is to remove the app.
Treat the homepage as a sample, not the whole store. The homepage shares components (header, footer, forms, cards) with every other template, so fixing a header issue once usually fixes it site-wide. But product, collection, and cart pages have their own templates and need their own checks.
A test is only useful if it leads to a change in the source. AccessifyAI suggests fixes to the actual theme code, the Liquid and CSS, and shows you a diff you preview before applying anything. A missing label becomes a real <label for="..."> in the form snippet. A failing contrast value becomes an updated color token in your stylesheet. A missing alt prompts you to write meaningful alt text in the product image field. The change ships in your theme code, survives a page reload, works without JavaScript, and is reviewable like any other commit. That is the opposite of injecting a runtime script and hoping it loads before a user needs it.
A caution worth repeating: AccessifyAI helps you find and address barriers, and it suggests code-level fixes you review before applying. It does not by itself guarantee legal compliance, and we never describe a scanned or fixed store as "ADA compliant." Compliance is a legal determination about your whole store and your jurisdiction, not an output of any single tool. In the US the ADA's Title III has been applied by courts to websites tied to a physical place of public accommodation, as in Robles v. Domino's Pizza, 913 F.3d 898 (9th Cir. 2019); in the EU the European Accessibility Act (EU directive 2019/882) and EN 301 549, which references WCAG, set the standard. A scan moves you toward those standards. It does not certify you against them.
The practical sequence is short. Scan your homepage to get a named list of WCAG failures. Group and prioritise them by criterion and conformance level. Fix the machine-detectable issues in your theme code, previewing each diff. Then plan manual and assistive-technology testing for the issues a scanner cannot judge.
You can start the first step now with a free scan of your homepage. When you want to turn findings into reviewed theme-code fixes, AccessifyAI is on the Shopify App Store, with a free tier to start and paid plans for stores that want deeper coverage.
No. A scan finds machine-detectable WCAG failures and is the right first step, but compliance is a legal determination that also depends on manual testing and your jurisdiction. No automated tool, including ours, makes a store "compliant" on its own. The FTC's 2025 settlement with accessiBe penalised exactly that claim.
A scanner reads your rendered HTML and reports which WCAG criteria fail, so you can fix the source. An overlay is a runtime JavaScript widget that adjusts the page in the browser without changing the underlying source code, which is what courts and audits assess. Fixing the source is the durable path.
WCAG 2.2 Level A and AA success criteria. AA is the level that legal frameworks such as the ADA in practice and the EU's EN 301 549 (referenced by the European Accessibility Act) treat as the working standard.
The free scan checks your homepage, which shares header, footer, and form components with the rest of the store, so it surfaces many site-wide patterns. Product, collection, and cart templates have their own markup and should be tested separately as you remediate.
No. AccessifyAI shows you a diff of each proposed change to your Liquid or CSS and you preview it before anything is applied. Nothing changes in your theme without your review.
Re-test after any theme update, after installing or removing an app, and before major sales events. Theme changes and third-party apps are the two most common ways new accessibility barriers get reintroduced.
Share:
Get accessibility tips by email
One short email per month with new guides and Shopify accessibility updates. No spam, unsubscribe anytime.