Key takeaways
- A website accessibility audit has four layers: an automated scan, a keyboard pass, a screen reader pass, and content and design checks. Running only the first one is not an audit.
- W3C is explicit that tools “can not determine accessibility, they can only assist in doing so.” A machine can prove an image has no
altattribute. It cannot judge whether the alt text is useful.- Scanning your homepage is not scanning your store. Sample one page per template, plus the interactive states: cart drawer, mobile menu, popups, quick view.
- Record findings in one issue log with page, WCAG success criterion, severity, and owner. Prioritise blocking issues first, then by how many pages the fix touches.
- Re-audit after theme changes, campaign builds, and app installs. App installs are the usual source of regressions, because they inject markup you did not write.
A website accessibility audit is the step most Shopify merchants skip, or rather, the step they think they have done because they ran a scanner once and got a score. A score is a starting point. It is not an audit, and it will not tell you whether a shopper using a keyboard can finish checkout.
This guide covers the audit method rather than the fixes or the law. Four layers, all runnable for free, on a real store, by someone who is not an accessibility specialist. If you want the legal picture instead, start with our guide to Shopify ADA and WCAG compliance.
Why you can trust us
Jacques has over 15 years of development experience and has helped many Shopify brands ship accessible, fast storefronts. We have been in the Shopify space for over four years and have worked with hundreds of Shopify brands on their storefronts. We build Fudge, an AI storefront editor with a 5.0 rating on the Shopify App Store and Built for Shopify status, so we spend our days in the theme layer where these issues actually live.
Why an automated scan is not an audit
Automated tools are good at what they do, and bounded in a way that is the whole reason a real audit has more than one layer.
The W3C Web Accessibility Initiative states the limit plainly: “Tools cannot check all accessibility aspects automatically. Human judgement is required.” The same page adds that evaluation tools “can not determine accessibility, they can only assist in doing so.”1
How much they miss depends on what you count.
- Counting success criteria, automation reaches a minority. Deque’s own report notes that the traditional method puts tools at roughly 16 of the 50 WCAG 2.1 Level AA criteria.2
- Counting issue volume, the number is higher. Across over 2,000 first-time audits, 13,000 pages and nearly 300,000 issues, Deque found automation caught 57.38% of recorded issues.2
Both are real and they measure different things. Automation finds a large share of the instances, because a few failure types repeat thousands of times and colour contrast leads them. It covers far fewer of the rules, and the rules it misses need a person.
The split is consistent:
| A scanner can prove | A scanner cannot judge |
|---|---|
An image has no alt attribute | Whether the alt text describes the image usefully |
| A contrast ratio is below 4.5:1 | Whether the tab order matches the visual order |
A <button> has no accessible name | Whether “Learn more” tells a screen reader user anything |
An input has no associated <label> | Whether an error message explains how to fix the entry |
The page has no lang attribute | Whether a keyboard user can close the cart drawer |
Everything in the right column is found by layers two, three, and four.
The four layers of a website accessibility audit
Run them in this order. Each is free, and each finds things the previous one could not.
| Layer | What it finds | Time on a first pass |
|---|---|---|
| 1. Automated scan | Contrast, missing alt, missing labels, empty controls | 1 to 2 hours across a page sample |
| 2. Keyboard pass | Focus traps, invisible focus, dead ends, broken tab order | 1 to 2 hours |
| 3. Screen reader pass | Meaningless names, unannounced updates, unusable flows | Half a day |
| 4. Content and design | Alt text quality, error messages, captions, zoom and reflow | 2 to 3 hours |
A first audit on a typical store is roughly two working days. Every audit after that is much faster, because you are checking a diff rather than the whole store.
Layer 1: the automated scan
Which free scanner to use
Four free tools cover this layer.
| Tool | Where it runs | Good for |
|---|---|---|
| axe DevTools (free extension) | Chrome, Edge, Firefox | The default first scan. Runs the axe-core engine against WCAG 2.0, 2.1, and 2.2 at A, AA, and AAA |
| WAVE | Chrome, Firefox, Edge | Visual overlay of issues on the page itself. Runs locally, so it works on password-protected and dev pages |
| Lighthouse | Built into Chrome DevTools | A single accessibility score plus a separate list of manual checks it explicitly cannot automate |
| Accessibility Insights for Web | Chrome, Edge | FastPass gives automated checks plus a visual tab-stop trace in under five minutes |
WAVE runs entirely inside the browser, so nothing is sent to a server and you can scan a password-protected preview theme. Trigger it with Control + Shift + U, or Command + Shift + U on a Mac. Accessibility Insights for Web is free and open source, made by Microsoft, and Shopify’s own theme accessibility docs recommend it alongside Lighthouse and WAVE.
One note on Lighthouse. The accessibility score is a weighted average of pass or fail audits, and a page gets no credit for partially passing one. Treat it as a smoke alarm, not a certificate. Shopify says the same of its own guidance: “Following only the best practices on this page doesn’t guarantee that your theme is completely accessible.”
Scanning your homepage is not scanning your store
Your homepage is one template. Your store is a dozen, each rendering different sections with their own images, forms, and controls. A clean homepage scan says nothing about your product page, and the product page is the one that matters.
Sample one page per template, then scan every one:
- Home
- A collection page, ideally one with filters and pagination
- A product page, ideally one with variants, a size guide, and reviews
- The cart page (and the cart drawer separately, see below)
- Search results, including the empty-results state
- A content page: an about page, a blog post, or an FAQ
- A customer account page if your store has accounts enabled
- Checkout, as far as you can reach it
Checkout needs a caveat. checkout.liquid is available only to Shopify Plus merchants, so on other plans the core checkout markup is Shopify’s rather than yours. Walk it and log what you find, but the fixes there are not in your theme.
Then scan the states, not just the pages. This is where Shopify themes fail most often, because these components are custom JavaScript and a scanner only sees what is currently in the DOM:
- The cart drawer, open
- The mobile menu and any mega-menu, open
- Any popup or newsletter modal, open
- Quick view on a collection page
- A quiz or product finder modal, mid-flow
- The predictive search panel, with results showing
Open the state first, then scan. A scan run against a closed drawer reports nothing about the drawer.
Most of what layer one returns is the same handful of issues repeating: contrast, alt text, labels, empty links and buttons. We cover the repair for each in how to fix the six most common Shopify accessibility failures.
Layer 2: the manual keyboard pass
Put the mouse away. Start on the homepage, press Tab, and keep going all the way to a completed test order.
What to check as you go:
- The skip link. The first Tab press on any page should reveal a “Skip to content” link. Many customised themes lose it.
- Visible focus. You must be able to see where you are at all times. A global
outline: nonein the theme CSS is the usual cause of an invisible focus ring. - Tab order matches visual order. Focus should move left to right, top to bottom. Absolutely positioned sections and sticky elements often break this.
- No focus traps. Open the cart drawer with the keyboard. Can you Tab through it and get back out? Can you close it with Escape?
- No dead ends. Every control you can click with a mouse must be reachable with Tab and operable with Enter or Space.
- Focus is not obscured. A sticky header, a cookie banner, or a floating chat bubble can sit on top of the element you just focused.
The four components that fail most often are the cart drawer, the mobile menu, quick view, and any app-injected popup. All four are modal or drawer patterns, and all four need the same three behaviours: focus moves into the panel when it opens, focus stays inside while it is open, and Escape closes it and returns focus to the control that opened it.
Log each failure and keep tabbing. Do not stop to fix anything mid-audit. Auditing and fixing are separate jobs, and mixing them is how audits never finish.
Layer 3: the screen reader pass
This is the layer people avoid, and the one that changes how you see your store.
Both credible options are free. VoiceOver is built into macOS and iOS at no cost and is turned on in Accessibility settings. NVDA is free on Windows, developed by NV Access, a registered charity.
Your first pass will be slow, because you are learning the screen reader while auditing the store. Budget half a day. The second audit takes an hour.
Start with one product page, which carries the most interactive complexity in a store. Listen for:
- Heading structure. Do the headings describe the page and nest sensibly?
- The product image. Does it announce something useful, a file name, or nothing?
- Variant selectors. Are swatches and dropdowns announced with a name and a current value? Colour swatches rendered as unlabelled divs are common.
- The quantity stepper. Do the plus and minus buttons say what they do?
- Add to cart. Is the button named, and is the cart update announced? “Added to cart” that appears without moving focus needs an ARIA live region, or the screen reader user never hears it.
- Price and stock changes. When a variant switch changes the price or shows “Only 2 left”, is that announced?
- Accordions. Shipping, returns, and description panels need
aria-expandedreflecting the real state.
Then repeat on the cart and through checkout. If you can complete a purchase with a screen reader alone, most of your risk is gone. If you cannot, you have found the issue that outranks everything else in your log.
Layer 4: content and design checks
The last layer is judgement work: resolving the criteria a scanner flags as “needs review”, and catching content problems no scanner sees.
Colour contrast. WCAG 2.2 criterion 1.4.3 requires at least 4.5:1 for normal text and 3:1 for large text, defined as 18 point, or 14 point bold. Criterion 1.4.11 requires 3:1 for interface components and meaningful graphics.3 Scanners catch most of this. Check the cases they miss: text over a photographic hero, text over a gradient, disabled buttons. Test button text against the button fill, not the page background.
Alt text quality, not just presence. A scanner passes alt="IMG_4021". A shopper gets nothing. Read every alt attribute in your sample and ask whether it conveys what the image conveys. Decorative images want an empty alt="" so screen readers skip them. Our guide on how to add alt text in Shopify covers the admin field and the theme side.
Link and button names. “Click here”, “Learn more”, and “Read more” fail when read out of context, and screen reader users routinely navigate by pulling up a list of links. Name the destination: “Read the size guide”.
Form labels and error messages. Every input needs a real associated label. Then trigger validation deliberately: submit the contact form empty, enter a malformed email in the newsletter field. The error must identify the field, say what is wrong in text, and not rely on a red border alone.
Video captions. Any video with speech needs captions. Auto-playing background video needs a pause control.
Text resize and zoom. Zoom to 200% and check nothing is clipped or overlapping. Then narrow the viewport to 320 CSS pixels and confirm the page reflows to one column with no horizontal scrolling. Sticky headers, wide tables, and multi-column sections are the usual failures.
For the criterion-by-criterion version of this layer, use our WCAG 2.2 AA checklist for Shopify.
How to record what you find
One spreadsheet. Not four tool exports and screenshots in a chat thread. Every finding gets a row:
| Column | Why it is there |
|---|---|
| Page or state | ”Product template” or “Cart drawer, open”, so the fixer can reproduce it |
| Issue | One sentence describing the behaviour, not the theory |
| WCAG success criterion | The number, for example 2.1.2. Makes the finding defensible and searchable |
| Severity | Blocking or degrading, see below |
| Where it lives | Theme code, admin content, or an app |
| Owner | A person, not a team |
| Status | Open, fixed, verified |
The “where it lives” column matters more than it looks. It separates three different kinds of work: theme code you control, admin content anyone can fix without a developer, and app-injected markup you may not be able to change at all.
How to prioritise the fixes
Two questions, in this order.
Is it blocking or degrading? A blocking issue means the task cannot be completed: a keyboard trap in the cart drawer, an unlabelled required checkout field, an add-to-cart button with no accessible name. Those are lost sales, and they are what a demand letter describes. A degrading issue makes the task harder but still possible: a low-contrast caption, vague alt text, a skipped heading level. Clear every blocking issue before any degrading one.
How far does the fix reach? Sort what remains by how many pages it touches. A missing label on the header search field is one change that clears the failure across the whole store. A weak alt text on one blog image is one image. Weight by traffic, since your product and collection templates carry most of your sessions.
The queue that falls out of those two questions is the real output of the audit.
How often to re-audit
Three triggers, plus a baseline.
- After a theme change. A theme update, a redesign, or a new custom section. Re-audit the templates it touched.
- After a campaign build. Landing pages built fast for a launch or BFCM are the ones that ship with an unlabelled email field and a 2.5:1 discount badge.
- After an app install. The big one.
- Quarterly, as a baseline, even when nothing changed.
App installs are the usual regression source. A storefront app injects markup you did not write and did not review: a review widget, an upsell drawer, a popup, a currency switcher, a chat bubble. It lands outside your theme’s conventions, does not inherit your focus styles, and is often a <div> with a click handler where a <button> belongs. Nothing in Shopify warns you that the app you just installed added a focus trap.
After every storefront app install, run a scan and a keyboard pass on the pages it appears on. Twenty minutes catches most of it.
An overlay is not an audit, and not a fix
Worth naming, because it is sold as a shortcut to all of the above.
Third-party accessibility overlays do not substitute for an audit or for the fixes. In April 2025 the FTC approved a final order requiring accessiBe to pay $1 million over claims that its AI product could make any website WCAG compliant.4 Sites running overlays still get sued, because the underlying markup is unchanged. We cover the case in our guide on why accessibility overlays fail.
The alternative is unglamorous and it works: find the issues, fix them in the theme, re-check. That is the model we built Fudge around. It reads your live theme, surfaces what is failing in your Liquid, CSS, and JavaScript, and fixes it in native theme code rather than injecting a layer over the top. Because the output is real code, it survives an uninstall and adds no extra script to the page, and it sits alongside the rest of your store editing work.
FAQ
Run four layers. Scan a sample of pages with a free tool like axe DevTools, WAVE, Lighthouse, or Accessibility Insights for Web. Then do a keyboard-only pass through checkout, a screen reader pass with VoiceOver or NVDA, and manual content checks for contrast, alt text quality, form errors, and zoom. All four tools and both screen readers are free.
About two working days for a first full pass on a typical Shopify store: one to two hours for the automated scan across a page sample, one to two hours for the keyboard pass, roughly half a day for the screen reader pass while you are still learning it, and two to three hours for content and design checks. Later audits are much faster.
No. W3C states that tools cannot determine accessibility and that human judgement is required. Counting WCAG success criteria, automation can test roughly 16 of the 50 WCAG 2.1 Level AA criteria. Counting issue volume, Deque measured 57% across 13,000 pages, inflated by contrast errors repeating. Neither number covers keyboard traps or meaningless alt text.
One page per template, not just the homepage: home, a collection page with filters, a product page with variants, the cart, search results including the empty state, a content page, an account page, and checkout as far as you can reach. Then audit the interactive states separately, with the cart drawer, mobile menu, popups, and quick view open.
VoiceOver on macOS and iOS, which is built in at no cost and enabled in Accessibility settings, or NVDA on Windows, which is free and developed by the charity NV Access. Start on a product page and listen for image announcements, variant selector names, and whether the add-to-cart confirmation is announced at all.
After any theme change, after any campaign or landing page build, after every storefront app install, and quarterly as a baseline. App installs are the most common source of regressions because they inject markup you did not write, which does not inherit your focus styles and often uses divs where buttons belong.
Blocking before degrading. A blocking issue stops someone completing a task, such as a keyboard trap in the cart drawer or an unlabelled checkout field. After those, sort by reach: a fix in the header clears the failure on every page, so it outranks a single image on a low-traffic blog post.
Footnotes
-
W3C Web Accessibility Initiative, “Selecting Web Accessibility Evaluation Tools”: “Tools cannot check all accessibility aspects automatically. Human judgement is required” and “Web accessibility evaluation tools can not determine accessibility, they can only assist in doing so.” https://www.w3.org/WAI/test-evaluate/tools/selecting/ ↩
-
Deque, “The Automated Accessibility Coverage Report”: 57.38% of issues detected by automation across over 2,000 first-time audits, 13,000+ pages and nearly 300,000 issues, measured by issue volume. The report notes the traditional criteria-based method covers roughly 16 of the 50 WCAG 2.1 Level AA criteria. https://www.deque.com/automated-accessibility-coverage-report/ ↩ ↩2
-
W3C, WCAG 2.2 Quick Reference: success criterion 1.4.3 Contrast (Minimum) requires 4.5:1 for normal text and 3:1 for large text (18 point, or 14 point bold); 1.4.11 Non-text Contrast requires 3:1. https://www.w3.org/WAI/WCAG22/quickref/ ↩
-
Federal Trade Commission, “FTC Approves Final Order Requiring accessiBe to pay $1 Million”, April 2025. https://www.ftc.gov/news-events/news/press-releases/2025/04/ftc-approves-final-order-requiring-accessibe-pay-1-million ↩
