Accessible Commerce Components: the WCAG Checklist That Sells More

Accessible ecommerce components are built to meet WCAG 2.2 AA on the parts of a storefront that generic accessibility advice usually skips: variant pickers, quantity steppers, cart drawers, filter panels, and image carousels. The fix is rarely a full rewrite — it is keyboard operability, correct ARIA roles and states, visible focus indicators, and color contrast checked against your actual theme, not a default. This guide walks through the checklist component by component, with the specific failure modes that show up in real commerce UI and how to close them.

Most accessibility guidance is written for generic web pages — forms, navigation menus, article content. Commerce interfaces have their own vocabulary of interactive widgets that generic advice does not cover well: swatch pickers built out of styled boxes rather than real form controls, "add to cart" buttons that fire async state changes with no announcement, sticky buy boxes that trap focus on mobile, and carousels that autoplay over product imagery a screen reader user never gets a chance to pause. Accessibility here is not just compliance risk — an unusable checkout flow or an unreadable price is a lost sale regardless of who is buying. This is the checklist we use when evaluating commerce components, including the ones in our own Shopify themes and Figma kits.

Why This Matters Beyond Compliance

WCAG 2.2 AA is the benchmark most legal and enterprise procurement processes reference, and it is a reasonable target for any commerce site regardless of jurisdiction. But treat the standard as a floor, not the goal. A shopper using a keyboard because a trackpad is broken, a screen reader because of low vision, or increased text size because a phone screen is small in bad light — none of these are edge cases in aggregate, and every one of them is a shopper mid-checkout with a payment method already in hand. Components that fail silently under these conditions do not throw errors; they just quietly lose the sale, and nothing in your analytics will tell you why the cart abandonment rate on a particular device class is high.

The Checklist, Component by Component

1. Variant and swatch pickers

Color and size swatches are the single most common accessibility failure in commerce UI, because they are almost always built as a row of styled boxes with click handlers rather than real form controls. The fix is to build them as a native radio group: a fieldset with a legend naming the option ("Color"), and each swatch as a visually restyled radio input paired with its own label, not a bare clickable element. This gets you keyboard navigation (arrow keys move between options in most browsers), a screen reader announcement of the option name and selected state, and correct behavior in browser autofill and password-manager-adjacent tooling for free. If a swatch represents an out-of-stock combination, mark the underlying input as disabled and say so in its label text rather than relying on a faded-out color alone.

Common failure

A swatch row where the selected state is communicated only by a CSS border or background color change, with no checked state exposed to assistive technology at all. A screen reader user hears "Color, Blue, Green, Red" with no indication which one is currently selected, and a sighted keyboard user sees no focus ring at all because the element never received real focus in the first place.

2. Quantity steppers

The plus/minus quantity stepper next to an add-to-cart button needs three things: the number input itself must have a real, associated label (visually hidden is fine, e.g. "Quantity"); the increment and decrement controls must be real buttons rather than clickable spans or icons with a click handler bolted on; and the current value change should be announced through a polite live region on the wrapper, so a screen reader user hears "Quantity, 3" after clicking increment without needing to re-focus the field. Set sensible minimum, maximum, and step values on the input so assistive technology and browser validation agree with your JavaScript logic instead of fighting it.

3. Add-to-cart feedback and cart drawers

Clicking "Add to cart" on most storefronts triggers a slide-out drawer or a toast notification with no accompanying announcement for non-visual users. Wrap the confirmation message in a polite live region so it is read out automatically without needing focus to move there. When a cart drawer opens, move focus into it — ideally to a heading or the close button — and trap focus inside while it is open, the same pattern used for any modal dialog. On close, return focus to the control that opened the drawer, usually the add-to-cart button that was just clicked. Skipping the focus-return step is one of the most common regressions we see even in themes that otherwise get this right, because it is easy to test the "open" path and forget the "close" path.

4. Filter and facet panels

Collection filtering — by size, color, price range, brand — is usually built with checkboxes and a collapsible panel per facet group. Each collapsible group should be a real disclosure: a button that exposes its own expanded or collapsed state and is properly associated with the panel it reveals. Checkbox groups need a fieldset and legend per facet ("Size", "Brand") so a screen reader user gets context for each option rather than a flat, unlabeled list of "Small, Medium, Large, Nike, Adidas." When filters apply live (updating results without a page reload), announce the result count change in a live region — "42 products found" — so keyboard and screen reader users get the same feedback a sighted user gets from watching the grid repaint.

5. Image galleries and zoom

Product image galleries need real alt text per image — not the product title repeated four times, but a description that differentiates angles ("Blue canvas sneaker, side profile" vs. "Blue canvas sneaker, sole detail"). Thumbnail navigation should be a button per thumbnail with an accessible name, and the active thumbnail should be indicated with a proper current-item state, not color alone. Zoom-on-hover or zoom-on-click interactions need a keyboard equivalent — at minimum, a visible "Zoom" button that a keyboard user can activate and a way to close the zoomed view with Escape. Autoplaying image carousels on a product page are rarely necessary; if you use one, it needs a visible pause control, because auto-advancing content that runs longer than five seconds with no way to stop it is a WCAG 2.2 failure on its own.

6. Sticky buy boxes and mobile bottom bars

A sticky "Add to cart" bar pinned to the bottom of the viewport on mobile is good for conversion, but it needs to sit correctly in the page's focus order and must never overlap or hide focused content underneath it. Test this by tabbing through the entire product page on a phone-sized viewport with a keyboard (or keyboard emulation) — if the sticky bar covers the element currently focused, that is a real failure users hit, not a theoretical one. Give the sticky bar a clear landmark grouping if it contains multiple controls (price, quantity, add-to-cart) so screen reader users can jump to it directly instead of tabbing through the entire page to reach it.

7. Star ratings and review widgets

Star rating displays are almost always rendered as a row of SVG or icon-font stars with no text equivalent, which announces as nothing to a screen reader or as a wall of unlabeled images. Add a visually hidden text equivalent — "4.5 out of 5 stars, 128 reviews" — as a single accessible name on the rating component, and hide the individual decorative star icons from assistive technology so they do not get announced one by one. If the rating is also a link to a reviews section, make sure the link's accessible name describes the destination, not just "4.5 stars."

8. Checkout forms and error states

Checkout is the highest-stakes accessibility surface on the entire site, because it is the one place a failure directly costs revenue rather than just traffic. Every input needs a real, programmatically associated label — placeholder text is not a label and disappears the moment a user starts typing, which is actively harmful for anyone relying on it to remember which field they are in. Validation errors need to be programmatically tied to their field, announced through a live region when they appear, and summarized at the top of the form on submit failure so a screen reader user does not have to hunt field-by-field to find what went wrong. Autocomplete hints for card numbers and shipping fields are also an accessibility win, not just a convenience feature — they let assistive technology and browser autofill cooperate instead of fighting each other on the most error-prone form on the site.

9. Focus indicators, across the whole component set

This is the single highest-leverage fix on this list because it is cross-cutting: every interactive element above needs a visible focus indicator that survives your theme's own styling. The most common accessibility regression we see in commerce themes is a global rule that removes the default outline for aesthetic reasons with no replacement focus style, which silently breaks keyboard navigation across the entire site at once. Style focus so it shows specifically for keyboard users rather than on every mouse click, and make sure the indicator has at least 3:1 contrast against its background per WCAG 2.2's non-text contrast criterion — a thin outline in a color close to the button background does not count.

10. Color contrast under your actual theme, not the default

Contrast ratios are the easiest check to run and the easiest to get wrong in practice, because most audits check the default theme state and never check sale-price red text on a white background, a "low stock" badge in orange on a light gray card, or muted secondary text on a tinted section background. Text needs 4.5:1 contrast at normal size and 3:1 at large size (roughly 18px bold or 24px regular) against whatever background it actually renders on — run this check per theme variant and per section background color, not once against a swatch in a style guide. Sale badges and out-of-stock labels are worth checking twice, since they are often styled by a second, less-reviewed component than the primary price text.

How to Test This Without a Full Audit Team

You do not need an accessibility consultancy to catch most of what is on this list. A workable routine: run an automated scanner (axe DevTools or Lighthouse's accessibility pass) on the product page, cart, and checkout templates as a first pass — it will catch missing labels, contrast failures, and missing ARIA attributes reliably, though it will miss keyboard-trap and focus-order problems entirely. Follow that with a manual keyboard pass: unplug your mouse, tab through the full purchase flow from product page to order confirmation, and note anywhere focus disappears, gets stuck, or jumps somewhere unexpected. Finally, turn on a screen reader (VoiceOver on Mac, NVDA on Windows, both free) for the same flow — you will find issues in ten minutes that no automated tool surfaces, particularly around live-region announcements and swatch/rating components.

• Automated scan — axe DevTools or Lighthouse on product, cart, and checkout templates; catches labels, contrast, and missing ARIA fast.
• Keyboard-only pass — tab through the entire purchase flow with no mouse; watch for lost focus, traps, and skipped controls.
• Screen reader pass — VoiceOver or NVDA through the same flow; listen for silent state changes on variant pickers, carts, and errors.
• Contrast check per theme state — sale price, low-stock badge, and muted text, on every section background they actually appear on.
• Reduced-motion check — confirm carousels, drawers, and hover zoom respect a user's reduced-motion preference rather than animating regardless.

Where This Fits as You Move Toward Headless and Component Libraries

If you are building or evaluating a component library for a headless storefront — whether that is a shadcn/ui-based Next.js build, a Medusa-backed custom frontend, or any other component-driven architecture — accessibility is far cheaper to bake in at the component level than to retrofit at the page level later. A radio-group-based swatch picker, a disclosure-based filter panel, and a focus-trap-aware cart drawer are the kind of primitives worth getting right once in a shared component and reusing everywhere, rather than re-solving per page. This is also where design tooling earns its keep: a Figma component library that encodes focus states, contrast-checked color pairs, and labeled form fields as part of the design system means engineering inherits accessible defaults instead of discovering gaps during a pre-launch audit. Our own Figma kits are built with this in mind for exactly that reason — worth a look at the Figma kit catalog if you are assembling a component library and want a starting point that already accounts for states like focus, disabled, and error rather than only the default look.

To be clear about where Polo Themes sits today: we build Figma UI kits and Shopify OS 2.0 themes, not a packaged component registry or a Next.js starter kit — those are a direction we are exploring, not a shipped product. What is above is the checklist we hold our own theme and kit components to, and it applies just as directly whether you are customizing a Shopify theme, building a design system in Figma, or hand-rolling commerce components for a headless frontend.

Frequently Asked Questions

Does WCAG 2.2 AA compliance require a full redesign of my storefront?

Almost never. Most failures come from a handful of specific gaps — missing focus indicators, swatches built without real form controls, unlabeled inputs, and silent async state changes — that can be fixed component by component without touching visual design at all.

What is the single highest-impact fix if I can only do one thing?

Restore a visible focus indicator everywhere it has been removed. It is a one-line CSS fix in most themes, it is cross-cutting across every interactive component, and a missing focus indicator is one of the most common reasons a keyboard user abandons a purchase flow entirely.

Are automated accessibility scanners enough on their own?

No. Automated tools catch structural issues reliably — missing labels, contrast failures, missing ARIA attributes — but they cannot detect a keyboard trap, a broken focus order, or a live region that never fires. A short manual keyboard and screen reader pass on the purchase flow catches what scanners miss.

Do accessibility improvements actually affect conversion, or is this purely a compliance concern?

Both. Compliance risk is real, particularly in checkout, but the more direct effect is that broken keyboard navigation, unlabeled form fields, and silent cart-update states cause real shoppers to abandon a purchase mid-flow — the same failures that fail an audit are the ones quietly losing sales in your funnel.