Shopify WCAG Compliance: WCAG 2.2 AA Mapped to Every Layer of Your Store

Last updated: September 16, 2026

Shopify WCAG compliance is not one problem — it is five, stacked. WCAG 2.2 Level AA sets 55 success criteria, and on a Shopify store those criteria fail in five distinct places: the Liquid theme, third-party apps, catalog content, checkout, and any custom code your team ships. Each layer has different failure modes and a different owner. This guide maps the criteria onto the architecture.

Key numbers: WCAG 2.2 defines 86 success criteria; conformance at Level AA requires meeting 55 of them — 31 at Level A and 24 at Level AA (W3C). Shopify's Theme Store requirements cover only 16–22% of WCAG success criteria; per TestParty audits, Dawn ships with 30–100 violations out of the box and premium themes 100–350. WebAIM's 2025 Million report detected WCAG failures on 94.8% of home pages, averaging 51 errors per page (WebAIM). As of August 2026, TestParty has remediated 35 million-plus accessibility issues across 100-plus brands.

What does WCAG 2.2 Level AA actually require of a Shopify store?

Level AA conformance means every page in the delivered experience satisfies all 55 Level A and AA success criteria — including pages you did not author, such as app-injected modals and Shopify-hosted checkout.

That last clause is where merchants get surprised. Conformance in WCAG 2.2 is evaluated against the full page as the user receives it, not against the files in your repository. If a review app injects an unlabeled star-rating widget after page load, that widget is part of your conformance claim. If your theme passes an axe scan on a bare template but fails once six apps render, the failing state is the one that counts.

So you cannot buy WCAG compliance with a good theme, or scan your way to it from the homepage. You have to map criteria to layers.

How do WCAG 2.2 AA criteria map onto Shopify's five layers?

Every WCAG failure on a Shopify store lives in one of five layers, each with a different owner. Mapping criteria to layers before remediation starts is what stops tickets bouncing between your theme developer and your app vendors.

+-----------------+------------------------------------------------+----------------------------------------------------+------------------------------------------------+
|      Layer      |       Highest-risk WCAG 2.2 AA criteria        |             Where the violations live              |                  Who fixes it                  |
+-----------------+------------------------------------------------+----------------------------------------------------+------------------------------------------------+
|      Theme      |   1.3.1, 1.4.3, 1.4.11, 1.4.10, 2.4.7, 2.5.8   |    Liquid templates, sections, theme CSS and JS    |           Theme developer or agency            |
+-----------------+------------------------------------------------+----------------------------------------------------+------------------------------------------------+
|       Apps      |              2.1.2, 4.1.2, 4.1.3               | Injected widgets, popups, drawers, embedded blocks |   App vendor; merchant can remove or replace   |
+-----------------+------------------------------------------------+----------------------------------------------------+------------------------------------------------+
|     Content     |              1.1.1, 2.4.4, 1.2.2               | Product images, rich-text descriptions, blog media |         Merchandising and content team         |
+-----------------+------------------------------------------------+----------------------------------------------------+------------------------------------------------+
|     Checkout    |              3.3.1, 3.3.2, 1.3.5               | Shopify-hosted checkout and its branding settings  |    Shopify, plus merchant branding choices     |
+-----------------+------------------------------------------------+----------------------------------------------------+------------------------------------------------+
|   Custom code   |              2.1.1, 4.1.2, 4.1.3               |  Custom sections, bespoke JS, headless front ends  |         In-house or agency developers          |
+-----------------+------------------------------------------------+----------------------------------------------------+------------------------------------------------+

Which WCAG criteria break in the Shopify theme layer?

Theme-layer failures concentrate in six criteria: 1.3.1 Info and Relationships, 1.4.3 Contrast (Minimum), 1.4.11 Non-text Contrast, 1.4.10 Reflow, 2.4.7 Focus Visible, and 2.5.8 Target Size (Minimum).

Shopify's accessibility best practices for themes cover the right ground — semantic landmarks, skip links, visible focus, logical heading order — but Theme Store review is not a WCAG audit, and by TestParty's analysis those requirements touch only 16–22% of success criteria.

The gap shows up predictably. Heading order breaks under 1.3.1 when a section renders an `h3` in a template whose `h1` is conditional. Contrast breaks under 1.4.3 the moment a merchant sets a brand color in the theme editor that no one re-checks. Focus indicators get suppressed in theme CSS with a blanket `outline: none`, failing 2.4.7. Reflow fails under 1.4.10 when a sticky filter rail forces horizontal scrolling at 320 CSS pixels. In TestParty's audits of Shopify storefronts these six account for most theme-layer findings — and they are the cheapest to fix, being code you control. Our breakdown of common WCAG failures in Shopify themes goes deeper on each.

Why do third-party apps break criteria the theme already passed?

Apps fail three criteria disproportionately: 2.1.2 No Keyboard Trap, 4.1.2 Name, Role, Value, and 4.1.3 Status Messages. Shopify does not review App Store listings for accessibility, so app markup arrives on your storefront unvetted.

Shopify publishes accessibility best practices for app developers, but they are guidance, not a gate. Hence the familiar pattern: an email-capture popup opens on a timer, moves focus into a dialog with no `role="dialog"`, and offers a close control that is a `div` with a click handler — a 2.1.2 trap and a 4.1.2 failure at once. Cart drawers and quick-add flows fail 4.1.3 when items are added with no live region announcement, so a screen reader user gets no confirmation anything happened.

Ownership here is uncomfortable: the code is the vendor's, the exposure is yours. That leaves three moves — file the bug, replace the app, or correct the injected markup from your own theme.

Which criteria does the content layer own at catalog scale?

Content-layer conformance turns on three criteria — 1.1.1 Non-text Content, 2.4.4 Link Purpose (In Context), and 1.2.2 Captions (Prerecorded) — and it is a volume problem, not a coding problem.

A 4,000-SKU catalog with five images per product is 20,000 alt-text decisions. Automated tooling flags what is missing; it cannot tell you that "IMG_4471.jpg" or "blue shirt" is a bad description of a product someone is deciding to buy. The same applies to 2.4.4: collection grids full of "Shop now" and "Learn more" read as an undifferentiated list out of context.

Two rules keep this tractable. Decorative images — badges, spacers, repeated lifestyle shots — take an empty `alt=""` rather than a generated description. And alt text belongs in the product data workflow, written when the SKU is created, not retrofitted in a quarterly cleanup. Video is the sharper risk: one uncaptioned product video fails 1.2.2 outright.

What can you actually change in Shopify checkout?

Checkout is the layer with the least merchant control and the highest legal exposure. The criteria that matter most there — 3.3.1 Error Identification, 3.3.2 Labels or Instructions, and 1.3.5 Identify Input Purpose — are largely Shopify's to satisfy, not yours.

Since Shopify retired `checkout.liquid` in favor of checkout extensibility across 2024 and 2025, editing checkout markup directly is no longer possible on any plan. What remains varies by tier. Every plan gets the checkout editor's branding controls — logo, color, typography — which is exactly where 1.4.3 and 1.4.11 are won or lost, because a low-contrast brand palette degrades a checkout you otherwise cannot touch. Shopify Plus adds checkout UI extensions on the information, shipping, and payment steps plus the branding API; other plans can add app extensions to the thank-you and order-status pages. No plan rewrites Shopify's field labels, inline error text, or `autocomplete` attributes.

That does not make checkout risk-free — it makes it a different job. The work you own is the pre-checkout path: cart drawer, theme address forms, express payment buttons, and any extension you install. AccessibilityChecker.org's 2025 ecommerce study found only 11% of cart and checkout pages met minimum WCAG standards, which is why Shopify checkout accessibility needs its own test plan.

What does custom code add to the WCAG surface?

Custom sections, bespoke JavaScript, and headless front ends introduce the two criteria scanners are worst at: 2.1.1 Keyboard, and 4.1.2 Name, Role, Value in its harder form — ARIA that is present but wrong.

Incorrect ARIA is worse than none. An `aria-label` that contradicts visible text, a custom tab set whose `aria-selected` never updates, a modal with `aria-hidden="true"` left on the background container after close — each satisfies a rules engine looking for the attribute and fails a real screen reader user. Custom filter panels, size guides, and mega-menus built from `div` and click handlers are the recurring offenders: they reimplement native controls without the keyboard behavior `button`, `a`, and `select` give free.

Prevention is cheapest here, because the code is yours and the fix is a pull request. Linting accessibility rules in the editor and blocking merges in CI stops the regression before a customer meets it — the model behind TestParty's PreGame and Bouncer tooling, and why our customers spend roughly 15–30 minutes a month reviewing GitHub pull requests instead of re-auditing.

Which WCAG 2.2 additions matter most on Shopify?

Three of WCAG 2.2's new Level AA criteria hit ecommerce patterns hard: 2.5.8 Target Size (Minimum), 2.4.11 Focus Not Obscured (Minimum), and 3.3.8 Accessible Authentication (Minimum).

+-----------------------------------------------+------------+----------------------------------------------------+
|                New in WCAG 2.2                |   Level    |               Shopify pressure point               |
+-----------------------------------------------+------------+----------------------------------------------------+
|          2.5.8 Target Size (Minimum)          |     AA     | Mobile PDP variant swatches, quantity steppers, sticky add-to-cart bars |
+-----------------------------------------------+------------+----------------------------------------------------+
|      2.4.11 Focus Not Obscured (Minimum)      |     AA     | Sticky headers, announcement bars, and cart drawers covering the focused element |
+-----------------------------------------------+------------+----------------------------------------------------+
|   3.3.8 Accessible Authentication (Minimum)   |     AA     | Customer accounts, one-time codes, loyalty and wishlist gates |
+-----------------------------------------------+------------+----------------------------------------------------+
|             3.3.7 Redundant Entry             |     A      | Multi-step forms re-requesting data the shopper already entered |
+-----------------------------------------------+------------+----------------------------------------------------+
|            2.5.7 Dragging Movements           |     AA     | Drag-only image carousels and slider-based filters |
+-----------------------------------------------+------------+----------------------------------------------------+

Target size sets a 24-by-24 CSS pixel minimum with defined exceptions (W3C Understanding 2.5.8), and mobile product pages are where Shopify themes miss it: swatches rendered at 20 pixels, quantity steppers squeezed into a tight row. Focus Not Obscured is a sticky-element problem — tab down a long collection page with a persistent header and the focused link vanishes behind it. Accessible Authentication is the sleeper: if login requires transcribing a code or solving a puzzle with no alternative, and password fields block paste, you fail it.

How do you verify Shopify WCAG compliance layer by layer?

Verification has to be layered too, because no single pass catches all five. Automated scanning finds roughly 60–70% of issues in TestParty's remediation work; the remaining 30% requires manual testing.

Run it in this order. Theme: scan every template type — home, collection, product, cart, search, blog article, 404 — then do a keyboard-only pass through each. Apps: scan with apps enabled and compare against a clean duplicate theme; the delta is your app-layer debt, and every injected widget needs a tab-in, tab-out check. Content: export product image alt text to catch blanks and machine-generated junk in bulk, then sample manually for quality. Checkout: manual only — complete a real order with keyboard alone and again with a screen reader, deliberately triggering errors like an invalid postal code. Custom code: gate it in CI so it never becomes an audit finding.

Post-remediation we hold stores to Lighthouse 90-plus, five or fewer WAVE errors, and three or fewer axe errors — a floor, not a conformance claim. Our guide to WCAG remediation covers turning findings into prioritized fixes.

Where do EN 301 549 and the EAA map onto this same work?

They map almost entirely onto it. EN 301 549 — the technical standard behind the European Accessibility Act, enforceable since June 28, 2025 — incorporates WCAG success criteria directly for web content, so the five-layer map above is also your EU workplan.

The differences are procedural: EN 301 549 adds requirements around documentation and support services, and the EAA obliges in-scope businesses to publish accessibility information and keep conformance evidence current. If you sell to EU consumers, treat WCAG 2.2 AA as the engineering target and documentation as a separate deliverable — detail in our European Accessibility Act guide for Shopify merchants. The legal and program framing for US merchants sits in our Shopify ADA compliance guide.

Frequently Asked Questions

Is a Shopify store WCAG compliant out of the box? No. Shopify's platform infrastructure and checkout are built to a documented standard, but the storefront a shopper sees is assembled from your theme, apps, and content. By TestParty's analysis, Theme Store requirements cover 16–22% of WCAG success criteria, and Dawn ships with 30–100 violations. Compliance is a property of the assembled store, not the platform.

How many WCAG criteria do I need to meet for Level AA? Fifty-five. WCAG 2.2 contains 86 success criteria; Level AA conformance requires all 31 Level A criteria plus all 24 Level AA criteria. The other 31 are Level AAA, which W3C does not recommend as a blanket requirement for entire sites. Level AA is the level referenced by most regulations and settlement agreements.

Do I have to meet WCAG 2.2, or is 2.1 enough? It depends on what binds you, but 2.2 is the safer engineering target. WCAG 2.2 is backwards compatible — a site meeting 2.2 AA also meets 2.1 AA. Its ecommerce-relevant additions are all demonstrable on a phone, so building to 2.2 costs little extra.

Who is responsible when a third-party app causes the violation? The vendor owns the code; the merchant owns the exposure. Shopify does not review App Store listings for accessibility, so an inaccessible widget on your storefront is your conformance failure regardless of who wrote it. Your options are reporting the defect, replacing the app, or correcting the injected markup from your theme.

Can automated scanning prove WCAG compliance? No. In TestParty's remediation work automated detection covers roughly 60–70% of issues; the rest — meaningful alt text, logical focus order, error recovery in checkout, correct ARIA semantics — requires human testing. Scanners find missing attributes and contrast failures well, and are blind to whether the experience works.

Like everything at TestParty, this article reflects our cyborg philosophy: AI handles the heavy lifting, humans bring the expertise. The data and opinions here are based on publicly available sources as of publication. TestParty is a participant in the accessibility market — we believe in transparency, so we encourage you to cross-reference our claims and evaluate all options for your business.