Shopify WCAG 2.1 AA checklist for EU agencies

Why a Shopify-specific checklist

A generic e-commerce WCAG checklist covers the universals: alt text, form labels, colour contrast, keyboard focus. That checklist applies here too. But Shopify stores have a specific architecture — a Liquid-rendered theme wrapping the storefront, a stack of third-party apps injecting JavaScript, and a native checkout that the merchant cannot rewrite — and the audit-report structure has to reflect that.

This page walks through the six Shopify-specific layers we audit on every store. The EU-agency framing matters: under the European Accessibility Act, the conformance obligation sits with the merchant, not with Shopify. Your job is to deliver a report that tells the merchant what they can change, what Shopify owns, and which apps they need to remove or replace.

1. Platform boundaries (before you start)

Every Shopify audit has to classify findings by who can fix them. This isn't optional — if you hand a merchant a list of 140 issues and 40 of them sit inside Shopify's native checkout, the merchant cannot act on those 40 items and will lose confidence in the report.

The three zones

• Merchant-owned. Theme code (Liquid templates, sections, snippets, schema-driven blocks), product content, CMS pages. The merchant can fix these — either in-house or through your agency.
• App-owned. Anything injected by a third-party Shopify App. The merchant can uninstall the app, contact the developer, or request a replacement — but cannot patch the injected HTML directly.
• Shopify-owned. Native checkout, admin-generated elements (e.g. Shop Pay buttons), platform-controlled error messages. The merchant has very limited customisation (checkout UI extensions on Plus; branding-level tweaks elsewhere).

2. Theme audit (the merchant-owned layer)

Most of the issues you will find live here. Even Shopify's own reference theme (Dawn) ships with solid foundations that degrade under merchant customisation — palette swaps that break contrast, logo-only headers that drop the accessible site name, hero carousels retrofitted with autoplay.

2.1 Start from a clean install comparison

Before you audit the live store, pull up a blank Dawn demo (themes.shopify.com/themes/dawn/styles/default) in a second tab. Any accessibility regression between the baseline and the live store was introduced by customisation — not by the theme vendor. This narrows the remediation scope considerably.

2.2 The five highest-ROI theme checks

• Brand palette colour contrast (SC 1.4.3). Run the merchant's full colour palette through a contrast checker. Primary button text, announcement bar text, on-sale badges, and review-star fills are the common failures. Shopify's theme editor lets merchants pick any hex — no guardrails.
• Predictive search keyboard support (SC 2.1.1). Dawn's predictive search should be keyboard-navigable by default, but custom search overlays (heavily customised stores often replace it) frequently trap focus or fail to announce results. Tab through it without a mouse.
• Mobile menu focus trap (SC 2.4.3, 2.1.2). Drawer / hamburger menus on mobile should trap focus when open and return focus to the trigger on close. Custom headers routinely break this.
• Product variant pickers (SC 1.3.1, 4.1.2). Colour swatches built as clickable <div> or <label> elements without radio semantics are one of the most common Shopify failures. They should be radio groups with accessible names that include the colour.
• Cart drawer (SC 4.1.3, 4.1.2). Ajax cart drawers should announce line-item additions and totals via aria-live. Most custom drawers we audit are silent — the screen-reader user never hears “added to cart”.

3. Liquid template accessibility

Shopify themes are rendered by Liquid, and several accessibility patterns are Liquid-specific enough to call out on their own.

3.1 Alt text from image.alt

Product and variant images have an alt field in the Shopify admin. Themes should render it via {{ image.alt | escape }} — not fall back to the product title (which is rarely descriptive of the specific image) or leave it blank. Audit every {% for image in product.images %} loop in the theme.

3.2 Dynamic heading levels in sections

Shopify sections often let merchants pick a heading tag via schema ({{ section.settings.heading_tag }}). This is good for flexibility but routinely produces pages with H1 → H4 → H2 sequences when the merchant changes order. Audit each template's heading hierarchy on the rendered page, not in the theme source.

3.3 Form errors from Shopify's form.errors

Contact forms, account forms, and newsletter signups surface server-side errors through form.errors. These error blocks must render with role="alert" and be linked to their fields via aria-describedby. Stock Dawn handles this well — many custom themes regress it.

3.4 Section settings that affect accessibility

Check the theme editor for settings the merchant can toggle that silently break accessibility: autoplay video, carousel autoplay, animation on scroll, parallax backgrounds, sticky headers that change height on scroll. Some of these fail WCAG 2.2.2 (Pause, Stop, Hide). Your report should call out which toggled-on settings contribute to the findings.

4. Third-party apps: the usual suspects

Every Shopify App you install is additional HTML, CSS, and JavaScript running on the storefront. Their accessibility is entirely in the hands of the app developer — and the average developer does not audit for WCAG before shipping.

Categories that consistently fail

• Review widgets (Judge.me, Loox, Yotpo, Stamped). Star ratings rendered as images without accessible names; pagination controls without visible focus; review carousels with no keyboard support.
• Cookie-consent apps (Pandectes, iubenda, Consentmo). The banner itself is often focus-trapped incorrectly, and settings modals frequently fail WCAG 2.4.3 (Focus Order).
• Live chat / bot widgets (Tidio, Gorgias, Intercom). Chat launchers without accessible names; input fields without labels; bot responses that don't announce via aria-live.
• Upsell / popup apps (Privy, Klaviyo forms, Optinly). Exit-intent popups that can't be dismissed with Escape, focus that escapes the modal, aggressive scroll-lock that traps keyboard users.
• Size-guide / fit apps (Kiwi Size Chart, Prime Size Chart). Modals without accessible names or ARIA dialog semantics; size tables that don't render <th scope="col">.
• Accessibility overlay apps (AccessiBe, UserWay, EqualWeb, accessiBility). These do not make a Shopify store compliant. We cover why in the overlay widgets vs audits comparison. If a merchant has one installed, your report should flag it and recommend removal.

5. Checkout (the Shopify-owned layer)

Shopify's native checkout (and now Checkout Extensibility for all plans) is the same code on every merchant's store. Shopify maintains it. Merchants cannot rewrite it.

For audit purposes, this means:

• Test the checkout flow end-to-end with a keyboard and with a screen reader. Document any failures you find, but be explicit in the report that the remediation path runs through Shopify's accessibility team.
• Audit Shop Pay, Google Pay, Apple Pay and PayPal express buttons. Their accessible names, focus states, and error handling vary by wallet.
• On Shopify Plus, audit any Checkout UI Extensions the merchant has installed separately — these are merchant-deployed code running in Shopify's checkout.
• For EAA purposes, the merchant's conformance statement should cite Shopify as the checkout vendor and document the merchant's own measures on the theme and apps. This is similar to how agencies cite payment gateways on the PCI-DSS side.

6. Audit workflow for Shopify stores

The workflow we use internally — adapt it to your own process:

1. 1Run an automated scan over 5–20 key templates (home, collection, product, cart, blog, account). Capture severity, selector, WCAG criterion, evidence.
2. 2Pull the app list from the merchant's Shopify admin. Tag each installed app and note which categories it falls into (review, cookie, chat, popup, size guide, overlay).
3. 3Manually test the five highest-value theme checks (contrast palette, predictive search, mobile menu, variant pickers, cart drawer) against the live store.
4. 4Walk the checkout flow end-to-end with a keyboard and a screen reader. Record findings separately.
5. 5Classify every finding by owner (merchant / app / Shopify) before writing the report.
6. 6Produce the report with a remediation plan that leads with merchant-owned fixes, then app replacements, then Shopify escalations.

Next steps

If you audit one Shopify store well, the pattern repeats. The merchant-owned / app-owned / Shopify-owned split is what turns a WCAG report into a remediation plan the merchant can actually execute — and the EAA conformance statement they need on file.

For broader context, read our general e-commerce WCAG checklist, the EAA compliance guide for agencies, and the overlay widgets vs audits comparison before your next conversation with a Shopify merchant considering an “accessibility app”.