WCAG 2.2 AA for Shopify: The Criteria That Trip Up Storefronts Most

TL;DR. WCAG 2.2 AA is the W3C standard most accessibility evaluations measure against. On a Shopify storefront, the same handful of success criteria fail over and over: contrast on buttons and badges, image alt text, unlabeled form fields, keyboard traps, and focus visibility. An automated axe-core scan catches roughly 30–50% of WCAG issues. The rest needs manual review by a qualified professional. This is documentation, not legal advice.

What WCAG 2.2 AA means for a storefront

The Web Content Accessibility Guidelines (WCAG) 2.2 are organized under four principles, often abbreviated POUR: content must be perceivable, operable, understandable, and robust. Under those principles sit individual success criteria, each assigned a conformance level of A, AA, or AAA. Level AA is the tier most evaluations target, so “WCAG 2.2 AA” means meeting every Level A and Level AA success criterion.

For a Shopify store, that translates into practical questions. Can a shopper read the price against its background? Can someone who navigates by keyboard reach the add-to-cart button and complete checkout? Will a screen reader announce a product image and a form field correctly? The criteria below are where storefronts most often fall short.

The criteria that trip up Shopify storefronts most

These recur across themes, apps, and custom Liquid sections. Each maps to a specific WCAG 2.2 success criterion published by the W3C.

• Color contrast (1.4.3 Contrast Minimum). Sale badges, accent buttons, placeholder text, and low-contrast “subtle” gray copy frequently fall below the required ratio. Theme color palettes that look elegant in a mockup often fail against the white space around them.
• Image alt text (1.1.1 Non-text Content). Product images imported in bulk routinely ship with empty, duplicated, or filename-style alt attributes (“IMG_4821.jpg”). Decorative images that should be hidden from assistive tech are sometimes announced instead.
• Unlabeled form fields (3.3.2 Labels or Instructions; 4.1.2 Name, Role, Value). Newsletter signups, search boxes, and checkout fields that rely on placeholder text instead of a real label leave screen-reader users guessing what to type.
• Keyboard traps (2.1.1 Keyboard; 2.1.2 No Keyboard Trap). Cart drawers, quick-view modals, and cookie banners can capture keyboard focus so a user cannot tab back out. App-injected widgets are a common culprit.
• Focus visibility (2.4.7 Focus Visible). Themes that strip the browser’s default focus outline for aesthetics leave keyboard users unable to see where they are on the page.
• Link and button names (2.4.4; 4.1.2). Icon-only buttons (a bare cart or search glyph) and repeated “Read more” links without an accessible name give assistive tech nothing meaningful to announce.

What WCAG 2.2 added

WCAG 2.2 introduced new success criteria on top of 2.1, several of which show up directly on a store. They are worth naming because older audits and older tools predate them.

• Focus Not Obscured (2.4.11, AA). When a sticky header or a chat bubble covers the element that just received keyboard focus, this criterion is at risk. Sticky announcement bars are a frequent offender.
• Dragging Movements (2.5.7, AA). Any interaction that relies on dragging (an image comparison slider, a drag-to-reorder cart) must offer a single-pointer alternative.
• Target Size minimum (2.5.8, AA). Small tap targets, like tightly packed quantity steppers or swatch dots, can fall below the minimum size unless spaced adequately.
• Consistent Help (3.2.6, A). If you offer a help or contact mechanism, it should appear in the same relative place across pages rather than moving around between the homepage, product page, and checkout.

What automated axe-core testing catches

Automated tooling is genuinely useful for the machine-detectable share of WCAG. An axe-core scan can reliably flag problems with clear programmatic signatures, including:

• Color-contrast ratios that fall below the AA threshold.
• Missing alt attributes and empty accessible names.
• Form controls with no associated label.
• ARIA misuse, such as invalid roles or required attributes that are absent.
• Document-structure problems, like skipped heading levels or duplicate IDs.

The honest ceiling here is well established. Industry analysis from Deque, the team behind axe-core, places automated detection at roughly 30–50% of WCAG issues. That figure is the realistic limit of any automated scanner, Paperfort included. A scan that returns zero errors has cleared the machine-detectable portion, not the whole standard.

What still needs manual checking

The remaining majority of WCAG criteria depend on human judgment, because they ask whether something is meaningful, not merely whether it exists. A tool can confirm an image has alt text; it cannot confirm the alt text describes the product. Areas that require manual review include:

• Alt-text quality. Whether the description conveys what matters about the image.
• Keyboard flow through a real purchase. Tabbing from product page to cart to checkout to confirmation, with no traps and a logical order.
• Screen-reader experience. Whether announcements make sense in sequence and dynamic updates (cart count, error messages) are conveyed.
• Focus order logic. Whether focus moves in a sensible reading order, not just whether focus is visible.
• Comprehension without sight. Whether the page still makes sense when you cannot see it.

These checks call for a qualified professional working through the storefront deliberately. No scanner substitutes for that.

A practical path

The efficient sequence is to handle the machine-detectable layer first, then plan for the rest. Run an automated WCAG 2.2 AA scan to get your baseline and a prioritized fix list for contrast, alt attributes, labels, ARIA, and structure. Ticket those to your developer, because they are concrete and fast to verify. Then schedule manual review for the keyboard, screen-reader, and judgment-based criteria a scan cannot reach.

Paperfort runs the automated axe-core scan and turns the results into documentation you can act on and share: an audit report with a prioritized remediation list, a completed VPAT 2.5, and a hosted accessibility statement for your own domain. It is documentation and a starting point, not a compliance guarantee. For the wider legal context, ADA digital-accessibility lawsuits topped 5,000 in 2025 including state filings, and roughly three-quarters of targets are e-commerce sites, per UsableNet tracking, while the European Accessibility Act has been enforceable for in-scope e-commerce services since June 28, 2025.

Ready to see where your storefront stands? Run a WCAG 2.2 AA scan of your store and get your machine-detectable baseline.