I Scanned 12 Shopify Themes. 91% of the Accessibility Errors Were Not Real.
I scanned all twelve of Shopify’s free themes against WCAG 2.2 AA — homepage, collection, product and cart, forty-eight pages in total.
The scanner reported 65 failing elements. Six of them were real.
The other 59 — 91% of everything reported — were false positives. They all came from a single theme, and that theme is Dawn: the default every new Shopify store starts on.
This matters because scan output is increasingly what gets sold as an accessibility audit, and what gets attached to demand letters. So it is worth knowing exactly how it fails.
What was tested
Twelve themes: Dawn, Refresh, Craft, Sense, Studio, Taste, Ride, Publisher, Origin, Colorblock, Spotlight and Crave — scanned on their public demo stores.
Four page types each: homepage, collection listing, product page and cart. Headless Chrome at 1440×900, axe-core 4.13, rules limited to WCAG 2.0/2.1/2.2 levels A and AA.
Each page was scanned under three separate conditions, each in a fresh browser page so that emulation could not leak between them:
- default motion settings, scanned without scrolling
- default motion settings, full page scrolled and allowed to settle
prefers-reduced-motion: reduce
That third condition is the one that produced the finding, and it was not what I was looking for.
The 59 false positives
Dawn’s collection page reported 27 colour-contrast failures. The scanner said the text was #fdfdfd on #ffffff — a contrast ratio of 1.01. White on white.
Dawn does not look like that. Reading the computed style of those same elements gives rgb(18, 18, 18) — near-black, roughly 16:1 against white. It passes comfortably.
The cause is in the selectors the scanner returned. They carry the class scroll-trigger--offscreen. Dawn animates elements as they enter the viewport, and an element that has not yet animated still computes the animation’s starting colour. The scanner reads that transient state and reports it as a permanent failure.
Across Dawn’s four pages this produced 59 phantom failures: 14 on the homepage, 27 on the collection page, 10 on the product page, 8 in the cart.
Two details that make this worse than a normal flaky test
It is perfectly repeatable. I ran the identical scan on Dawn’s collection page twenty times. Every single run returned 27. Not a range, not an average — 27, twenty times out of twenty.
This is the part that should concern anyone relying on scan output. A careful tester who suspects a fluke will re-run the scan. The scan will confirm itself. Repeatability reads as reliability, and here it is neither.
The variable is an accessibility setting. Run the same scan with prefers-reduced-motion: reduce and all 59 disappear. Same page, same scanner, same second.
The animations never start, so the starting state never applies, so there is nothing for the scanner to misread. Which means a tester who has switched on the operating system setting for reduced motion — often someone with vestibular sensitivity, a person the setting exists to protect — sees a clean report. A tester who has not sees 59 errors.
Turning on an accessibility feature changes the accessibility test result. Neither tester has any way of knowing that from the report.
The six real failures
Six elements failed under every condition. Eight of the twelve themes had none at all. I confirmed each one by reading the live computed styles rather than trusting the scanner a second time.
Four are contrast failures caused by the same design decision. Craft, Origin and Colorblock render secondary text at 85% opacity. That is a reasonable-looking choice in a design tool and it is what pushes the text under the threshold:
- Craft — footer policy links, 4.47:1 against a 4.5:1 requirement
- Colorblock — a homepage banner link, 4.49:1
- Origin — a rich-text link, 3.49:1
Two of those fail by hundredths of a point. That is not a technicality to wave away — the threshold is where it is for a reason — but it is worth knowing that the fix is one opacity value, not a redesign. Origin’s 3.49:1 is a clear miss and needs a real colour change.
One is a genuine keyboard barrier, and it is the only finding here that would actually stop someone. Studio’s homepage slideshow is a horizontally scrollable region with no keyboard focus and no focusable content inside it (SC 2.1.1). A mouse user scrolls it. A keyboard user cannot reach the content at all.
That last one is the only failure on this list that I would prioritise on a real engagement.
What the themes actually get right
I also tested keyboard basics by hand rather than by scanner, walking up to forty tab stops per theme and comparing the computed style of each focused element against its unfocused state.
All twelve themes ship a working skip link as the first tab stop. Every visible tab stop tested had a genuine focus indicator — an outline, a shadow or a colour change that actually renders.
Shopify’s free themes are, on this evidence, built with real care. That deserves saying plainly.
So why do merchants on these themes still get demand letters?
Because none of what I tested is where accessibility actually breaks on a live store.
A demo store is a theme in its original state. A real store is that theme plus a merchant’s colour choices in the theme editor, plus six apps injecting markup, plus a custom section a developer added two years ago, plus product descriptions pasted from Word.
And the failures that generate complaints are mostly behavioural — the things a scanner structurally cannot check:
- Focus not moving into the cart drawer when it opens, and not returning when it closes (SC 2.4.3)
- Keyboard traps in quick-view and size-guide modals (SC 2.1.2)
- Sold-out variants marked only by a strike-through (SC 1.4.1)
- Filters that replace the product grid with no announcement (SC 4.1.3)
- Validation errors shown as a red border and nothing else (SC 3.3.1)
- Focus indicators that exist but are hidden behind a sticky header (SC 2.4.11)
Every one of those requires a person with a keyboard and a screen reader. None of them appear in a scan report.
What to take from this
Automated tools detect roughly 30% of WCAG failures. That number is widely quoted and it is roughly right — but it understates the problem, because it implies the 30% is at least correct. On the theme set above, 91% of what the scanner reported was wrong.
So the honest description of a scan is: it catches a minority of real failures and adds invented ones, and it gives you no way to tell which is which.
That does not make scanners useless. I use them. They are a fast first pass over a large site and they catch genuine structural problems at a scale no human matches. They are a starting point.
Three practical things follow:
- Verify every finding before you act on it. Open the element, read its computed colour. It takes seconds and it is the difference between a finding and a guess.
- Record the conditions with every result — viewport, motion preference, whether the page was scrolled, browser and tool versions. A result without its conditions cannot be reproduced, and this article is the reason why.
- If someone hands you a report that is raw scan output, ask what was verified by hand. If the answer is nothing, you have bought a list, not an audit.
The data
Scanned 20 September 2026 with axe-core 4.13 in headless Chrome at 1440×900, against the public Shopify theme demo stores.
| Theme | Flagged (default browser) | Reproducible under all conditions | Rules genuinely failed |
|---|---|---|---|
| Dawn | 59 | 0 | — |
| Refresh | 0 | 0 | — |
| Craft | 2 | 2 | color-contrast |
| Sense | 0 | 0 | — |
| Studio | 1 | 1 | scrollable-region-focusable |
| Taste | 0 | 0 | — |
| Ride | 0 | 0 | — |
| Publisher | 0 | 0 | — |
| Origin | 2 | 2 | color-contrast |
| Colorblock | 1 | 1 | color-contrast |
| Spotlight | 0 | 0 | — |
| Crave | 0 | 0 | — |
The full per-theme, per-page, per-condition results are published as raw data: shopify-theme-scan-2026-09-20.json. The point of publishing a number is that someone else can check it.
These numbers are a snapshot taken on that date. Themes get updated and scanners get updated, so if you are testing today, run it yourself rather than trusting a figure with a date on it — which is rather the point of publishing the method alongside the result.
If you want to know where your own store stands, a scan will not tell you. An audit gives you findings mapped to individual success criteria, prioritised by what actually blocks a purchase, with each one confirmed by hand. Remediation and certification run through EcomBack, a court-approved accessibility provider.
Book a consultation or read about accessibility services.
I am a web accessibility specialist and ADA compliance consultant — a participant in the W3C Accessibility Guidelines Working Group, DHS Trusted Tester and NVDA Expert certified. More about my background.