WCAG 2.2 AA Checklist for Shopify Stores

TL;DR. WCAG 2.2 AA is the W3C standard most accessibility evaluations measure against, and it is the practical bar for Shopify merchants who want defensible documentation. This checklist covers the success criteria that matter most on a storefront, grouped by topic. For each item, it notes whether an automated axe-core scan can detect the problem or whether it requires manual review. A checklist is a starting point, not a conformance claim. Passing every item here does not mean your store conforms to WCAG 2.2 AA; full conformance requires manual evaluation by a qualified professional.

Images and media

• 1.1.1 Non-text Content (A). Every product image, banner, and icon needs either a descriptive alt attribute or an explicit empty alt="" if it is purely decorative. Filename-style values like IMG_4821.jpg do not satisfy this. Automated: partially. A scanner flags missing or empty alt attributes, but cannot judge whether the description is accurate or useful.
• 1.2.2 Captions Prerecorded (A). Any prerecorded video with audio on your store needs synchronized captions. Product demo videos and brand reels are common gaps. Automated: no. A scanner can detect a video element but cannot read or evaluate captions.

Color and contrast

• 1.4.1 Use of Color (A). Information must not be conveyed by color alone. A required-field indicator that is only red, or a sale badge that relies only on a color change, fails this. Automated: partial. Tools flag some patterns but miss semantic context.
• 1.4.3 Contrast (Minimum) (AA). Normal text needs a contrast ratio of at least 4.5:1 against its background; large text (18pt or 14pt bold) needs 3:1. Sale-price red, muted placeholder text, and “subtle” gray copy against off-white backgrounds are frequent failures. Automated: yes, for solid backgrounds. Gradients and overlapping layers can fool scanners.
• 1.4.11 Non-text Contrast (AA). UI components like quantity input borders, checkbox outlines, and button edges need a 3:1 ratio against their background. Minimalist themes often strip these. Automated: partially. Scanners catch some component-contrast failures but miss many in practice.

Forms and checkout

• 3.3.2 Labels or Instructions (A). Every form field needs a visible label, not just placeholder text. Placeholder text disappears when the user types and is not announced reliably by screen readers. Newsletter signups and search boxes are common offenders. Automated: partially. Scanners flag fields with no programmatic label but may miss cases where label association is broken.
• 4.1.2 Name, Role, Value (A). Interactive elements need an accessible name, a correct role, and state information that assistive technology can read. Icon-only cart buttons, custom dropdowns built with div elements, and quantity steppers without labels all fail here. Automated: partially. Missing accessible names are detectable; incorrect custom roles and state mismatches are harder to catch.
• 3.3.1 Error Identification (A). When a checkout form field fails validation, the error must be identified in text and describe the problem. A red border alone does not satisfy this. Automated: no. Scanners cannot submit forms and observe error states.

Keyboard and focus

• 2.1.1 Keyboard (A). Every function available by mouse must also be reachable by keyboard alone. Carousels, color swatches, size selectors, and cart drawers are all candidates for keyboard failure. Automated: no. Scanners analyze code structure but do not operate the interface.
• 2.1.2 No Keyboard Trap (A). A keyboard user who moves focus into a modal, drawer, or cookie banner must be able to move focus back out. App-injected overlays are a common source of traps. Automated: no. Detecting a trap requires live keyboard navigation.
• 2.4.7 Focus Visible (AA). Every interactive element must have a visible focus indicator when it receives keyboard focus. Themes that remove the default browser outline for aesthetic reasons fail this unless they supply a replacement. Automated: partially. Scanners detect when outline: none or outline: 0 is applied with no alternative, but miss low-contrast custom indicators.

New in WCAG 2.2

These four criteria were added in WCAG 2.2. Older audits and tools built before September 2023 may not have evaluated them.

• 2.4.11 Focus Not Obscured (AA). When a component receives keyboard focus, it must not be completely hidden by sticky or fixed content. Sticky announcement bars, persistent chat bubbles, and cookie banners that overlap the focused element all put this criterion at risk. Automated: no. Requires live keyboard navigation while observing sticky elements.
• 2.5.7 Dragging Movements (AA). Any interaction that relies on dragging, such as an image zoom slider, a drag-to-reorder feature, or a pull-to-dismiss gesture, must have a single-pointer alternative (a button click or tap). Automated: no. Requires understanding of what the interaction does.
• 2.5.8 Target Size (Minimum) (AA). Interactive targets must be at least 24 by 24 CSS pixels, or have sufficient spacing so the target area reaches that size. Small swatches, icon buttons, and tightly packed quantity steppers are common failures on mobile. Automated: partially. Scanners can measure rendered size but have trouble with spacing-based exceptions.
• 3.2.6 Consistent Help (A). If your store provides a help or contact mechanism (a chat widget, a link to your support page), it must appear in the same relative position across all pages rather than shifting between the product page, cart, and checkout. Automated: no. Requires reviewing multiple page types.

Structure and navigation

• 1.3.1 Info and Relationships (A). Structure that is communicated visually must also be available programmatically. A heading that is styled large but marked up as a div, a data table rendered as floated div rows, or a list of product features with no ul all fail this. Automated: partially. Scanners flag some structural issues but miss many semantic mismatches.
• 2.4.4 Link Purpose in Context (A). A link’s purpose must be clear from its text or its immediate context. Repeated “Read more” and “Shop now” links without distinguishing context fail. Icon-only links with no accessible name also fail. Automated: partially. Scanners flag links with no text content but cannot judge whether the text is distinguishable in context.

How to check your store

Automated testing is a practical first step. Industry research commonly puts automated detection at roughly a third to half of WCAG issues. That is the honest ceiling: a scan that returns zero errors has cleared the machine-detectable layer, not the full standard.

The efficient sequence: run an automated scan to get a concrete, prioritized list of contrast failures, missing labels, ARIA errors, and structural problems. Fix those with your developer. Then schedule manual review for keyboard flows, screen-reader testing, and the judgment-based criteria no scanner reaches.

Start with the machine-detectable layer. Run the free Paperfort accessibility scan on your store URL and get a prioritized report of what axe-core finds, at no cost.