A Shopify accessibility checker should scan your key pages against WCAG 2.1 AA, show every finding with its rule id, impact, success criterion, selector and an HTML snippet, and mark which findings are fixable in the page versus manual work — because a checker that only prints a score tells you nothing you can act on.
Everything after that sentence is interpretation: how to read a finding without over-trusting it, what separates a findings-only checker from one that also fixes, and what should exist after the check besides a number.
What every finding must carry
A finding without coordinates is a rumour. These five fields turn it into a task someone can complete:
| Field | What it answers |
|---|---|
| Rule id | Which automated rule fired — reproducible across scans |
| Impact | How severe it is: high, medium or low |
| WCAG criterion | Which success criterion it violates, e.g. contrast or name-value |
| Selector | Exactly which element on which page |
| HTML snippet | What the offending markup looks like right now |
Grouping matters as much as the fields. One theme bug can raise the same rule on forty products; grouped by rule and page, you fix the template once instead of clicking through forty identical entries. Grouped by nothing, the checker becomes a backlog that grows faster than you clear it.
Findings-only versus findings-plus-fixes
Two checker families exist, and they are not interchangeable.
- Findings-only tools — browser extensions, one-off crawls — produce a list you then fix by hand in the theme editor. Cheap to run, easy to start, and every fix is your own code to maintain.
- Findings-plus-fixes tools apply changes to the page for you, which is where the risk lives. The safe design: fixes delivered through a theme app extension rather than edits to your theme files, a preview state gated behind a token only your browser holds, and one-click revert on everything.
Nine fixes is a realistic catalog for a Shopify storefront: six safe ones you can leave on by default, three riskier ones that should be off until you have previewed them. The preview step is the whole safety story — a link with a 30-minute token applies the rule only for you, so no shopper ever sees a change before you do.
Findings-only checkers stop before the hard part
A scanner that reports problems and walks away leaves you with the expensive half: deciding which findings matter, who fixes them, and whether anything regressed next month. Ask a checker what happens after the report — the answer separates a demo from a tool.
How to interpret the output honestly
Four reading rules prevent the two classic mistakes:
- Never read “not tested” as pass. A criterion an engine cannot evaluate stays untested forever; only a person closes it.
- Read impact, then read the criterion. Impact tells you urgency; the criterion tells you what conformance actually requires.
- Count themes, not instances. Forty contrast failures on one template is one bug with a wide blast radius.
- Separate fixed-by-embed from manual. Anything still marked manual after the embed ran — alt text, heading order, focus behavior — is your team’s work queue.
Automated engines cover only part of WCAG 2.1 AA, so the checker’s output is the machine half of an audit. Keyboard, focus order, zoom and reflow, and screen-reader passes still need a person (the checklist is in our Shopify WCAG audit guide).
What should exist after the check
Three artifacts, in order of usefulness: a dated report that marks every WCAG 2.1 AA criterion pass, fail or not tested; an accessibility statement published at a stable URL on your own domain with its date refreshed by the latest scan; and regression alerts, so the next theme update that reintroduces a bug does not wait for your next manual pass.
Start with the free WCAG Check Shop tool — paste your homepage URL and see which WCAG 2.1 AA findings it has in seconds. When you want the page set, the fixes and the dated documents, Capyo: Accessibility WCAG EAA scans 5 pages weekly on its free plan, with the PDF Prüfbericht and the published statement from $29/month.
What should a Shopify accessibility checker check?
The purchase flow — home, cart, search, top collections and products, contact and a policy page — against WCAG 2.1 AA, reporting each finding with rule id, impact, criterion, selector and HTML snippet, and marking what is fixable in the page versus manual work.
Is an accessibility score meaningful?
Only as a trend line. A single score hides which criteria failed and whether they were tested at all; the criterion-by-criterion pass, fail or not tested list underneath it is the output you can act on and hand to someone else.
What is the difference between a checker and an audit?
A checker runs automated rules against rendered pages. An audit adds human testing — keyboard, focus order, zoom, forms under error, screen reader — and a written conclusion. The checker supplies the machine half of the audit, not the whole.
Will a checker change my Shopify theme?
It should not. Fixes belong in a theme app extension you enable in the theme editor, previewable behind a token and revertible in one click. A tool that writes directly into your theme files hands you maintenance debt with every theme update.
What do I do with findings the tool cannot fix?
They become a named work queue: alternative text written by a person, heading order, focus management, labels and error messages. Findings-plus-fixes handles the mechanical six; the manual list is where a store actually distinguishes itself.
Free tool
WCAG Check Shop
Free check: see which WCAG 2.1 AA findings your homepage has in seconds.
Open the free toolCapyo is an independent app, not affiliated with or sponsored by Shopify. "Shopify" is a trademark of Shopify Inc. The app reports axe-core findings against WCAG 2.1 AA / EN 301 549 and generates document templates; it is not legal advice and it does not promise any legal outcome. The accessibility statement the app generates is a template to be reviewed by a lawyer, and the shop operator is responsible for its content and accuracy.