Shopify Accessibility Audit: 7 Theme Patterns That Fail WCAG 2.2

Most accessibility advice is written for websites in general. Shopify stores are not websites in general. They are built from a theme that follows shared conventions, extended by apps that inject markup nobody reviewed, and terminated by a checkout the merchant does not control.

That structure means the failures repeat. The same seven patterns turn up across stores running different themes, because they come from how Shopify themes are conventionally built rather than from any one theme’s mistake. Each maps to a specific WCAG 2.2 success criterion, and each can be checked in under a minute without a specialist.

WCAG 2.2 became a W3C Recommendation on 5 October 2023. It added several criteria that Shopify themes fail almost structurally — which is why an audit written against 2.0 or 2.1 will pass a store that 2.2 fails.

1. Variant swatches that are not controls

Colour and size pickers should be radio inputs with labels. A large number of themes render them as <div> or <span> elements with a JavaScript click handler, styled to look like buttons.

The visual result is identical. The functional result is that the control does not exist for anyone not using a mouse. It cannot be reached by Tab, it has no role, and it announces nothing.

Fails: SC 2.1.1 Keyboard (A) and SC 4.1.2 Name, Role, Value (A). If the selected swatch is indicated only by a border below 3:1 against its surroundings, also SC 1.4.11 Non-text Contrast (AA).

Test: Open a product page, press Tab repeatedly, and try to change from the default variant without touching the mouse.

2. Sold-out variants marked with a strike-through

An unavailable size is typically shown with a diagonal line through the swatch, or greyed out. Visually this is clear. To a screen reader the swatch is unchanged — same label, same state, still apparently selectable.

Fails: SC 1.4.1 Use of Color (A). The information is conveyed by a visual treatment alone.

Fix: the state belongs in the markup — aria-disabled="true" plus text that says what the styling implies, not only styling.

3. Every product image with the same alternative text

The common theme default is to fall back to the product title when an image has no alt text of its own. A gallery of eight images then announces “Ribbed Wool Sweater” eight times.

That is technically not empty, which is why scanners pass it. It is also useless. The gallery exists because the images differ — the back, the fabric close-up, the size chart. None of that reaches a screen reader user.

Fails: SC 1.1.1 Non-text Content (A). The size chart image is the one that matters most: if it is an image of a table with no text equivalent, the information is simply not available.

Test: Inspect three images in a product gallery. If the alt attributes are identical, you have found it.

4. The cart drawer that does not move focus

Add to cart, and a panel slides in from the right. Where is keyboard focus? On most stores, still on the Add to Cart button behind the overlay. Tab continues through the page underneath. The drawer is a dialog in appearance only.

Fails: SC 2.4.3 Focus Order (A) and SC 4.1.2 Name, Role, Value (A) — the panel needs role="dialog", aria-modal="true", an accessible name, focus moved into it on open, focus contained while open, Escape to close, and focus returned to the trigger afterwards.

Separately: if nothing announces that the item was added, that is SC 4.1.3 Status Messages (AA).

5. Sticky headers that cover the focused element

Announcement bar, sticky header, sometimes a sticky Add to Cart bar at the bottom. Tab down the page and eventually the element receiving focus scrolls under one of them. It has focus. You cannot see it.

Fails: SC 2.4.11 Focus Not Obscured (Minimum) (AA). This criterion is new in WCAG 2.2, which is why it is so widely failed — sticky furniture is near-universal in Shopify themes and was not a conformance problem under 2.1.

Test: Tab slowly down a long collection page and watch whether the focus indicator disappears behind the header.

6. Targets below 24 by 24 CSS pixels

Quantity steppers, drawer close buttons, colour swatches, filter checkboxes, the small “x” on an applied filter. These are routinely drawn at 16 or 20 pixels.

Fails: SC 2.5.8 Target Size (Minimum) (AA), also new in WCAG 2.2. The target must be at least 24 by 24 CSS pixels, or spaced so a 24-pixel circle centred on it does not overlap another target. The requirement covers the clickable area, not the icon — padding counts.

7. Filters that change results silently

Collection filtering updates the product grid over AJAX. The page does not reload. For a sighted user the change is obvious. For a screen reader user, nothing happened: no announcement, no focus movement, and often the focus point is destroyed when the grid re-renders.

Fails: SC 4.1.3 Status Messages (AA). A live region announcing “24 products” after filtering is a small change with a large effect.

What a theme audit does not cover

Two things sit outside the theme, and both get missed.

Apps. Review widgets, popups, chat, loyalty bars and upsell modals inject markup into your pages that your theme developer never wrote and cannot easily fix. An email capture modal that appears on a timer and cannot be dismissed with Escape is a keyboard trap — SC 2.1.2 (A) — and it is arriving from a third party. Audit the rendered page, not the theme repository.

Checkout. On standard Shopify plans, merchants do not control checkout markup. That is Shopify’s surface, not yours. It is worth knowing exactly where your responsibility ends, because it changes what you can remediate and what you can only report. Everything up to the checkout handoff is yours.

Running the first pass yourself

You do not need to buy an audit to find out whether you have a problem. You need thirty minutes.

• Unplug the mouse. Complete a purchase using only the keyboard: search, product page, variant selection, add to cart, cart, checkout handoff. Write down every point where you get stuck or cannot tell what is focused.
• Turn on VoiceOver (Command + F5 on macOS) or NVDA (free, Windows). Listen to one product page. Do the images tell you anything? Is the price announced? Does an add-to-cart do anything audible?
• Zoom the browser to 400%. Does the layout reflow, or does it require horizontal scrolling? That is SC 1.4.10 Reflow (AA).
• Submit the contact form with an error. Is the error announced and tied to the field it belongs to? SC 3.3.1 (A) and SC 3.3.2 (A).

This will not produce a conformance report. It will tell you within half an hour whether your store is usable without a mouse, which is the question most merchants actually want answered first.

What automated scanning will and will not find

Automated tools are good at contrast ratios, missing form labels, empty links and missing alt attributes. They are reliable for those and worth running on every deploy.

They cannot tell you whether the alt text is useful, whether focus order makes sense, whether a drawer behaves as a dialog, or whether a filter announced its result. Six of the seven patterns above will pass a scanner. That gap is the reason stores with a clean automated report still receive complaints.

Worth noting for anyone maintaining an older checklist: SC 4.1.1 Parsing was removed as obsolete in WCAG 2.2. If your tooling still reports duplicate IDs as a conformance failure, it is testing against a superseded version.

What to hand a developer

A findings list is only useful if it can be worked. Each issue needs the URL and element, the success criterion number, what happens now, what should happen, and whether it blocks a purchase. “Improve accessibility of product page” is not a ticket. “Variant swatches on /products/* are div elements with click handlers; convert to radio inputs with visible labels — SC 2.1.1, SC 4.1.2; blocks variant selection by keyboard” is.

Fix in this order: anything blocking the purchase path, then the product and collection templates, then everything else. A blocked checkout is a lost customer today, independent of any legal question.

Where the legal exposure sits

Which rules apply to your store depends on where you sell and who you sell to — I have written separately on which accessibility law applies to your store, and on what to do in the first hour after a demand letter arrives.

The short version for a merchant selling into the United States: the barriers that generate complaints sit in the purchase path, which is precisely where the seven patterns above live. I am not an attorney and none of this is legal advice — on any specific letter or claim, talk to counsel.

Do it once, then keep it

Stores regress. The theme gets updated, apps get added, a landing page gets built by someone who was not part of the original work. Two habits prevent it: components checked before they ship, and a re-test after any theme update or app install. Neither is expensive once the first pass is done.

If you want the full pass

An audit produces the findings mapped to specific success criteria, prioritised by what blocks a purchase, tested manually with a screen reader and by keyboard rather than by scanner alone, and written so your developers can act on it. Remediation runs through EcomBack, a court-approved accessibility provider.

Book a consultation or read about accessibility audits.

I am a web accessibility specialist and ADA compliance consultant, a participant in the W3C Accessibility Guidelines Working Group — the group that authors WCAG — and a DHS Trusted Tester. I am not an attorney and this is not legal advice. More about my background.