An online store is a chain of interactions, and a single inaccessible link breaks the whole chain. A shopper who cannot operate the size selector never reaches the cart; a shopper who cannot hear that the cart updated never reaches checkout; a shopper whose payment form rejects their password manager abandons the order at the last step. That is why this checklist is organized by journey stage — product pages, then cart, then checkout — rather than by WCAG principle. Test the journey end to end and you test what actually decides whether someone can buy from you.
The standard behind every item below is the Web Content Accessibility Guidelines. WCAG 2.2, published in October 2023, matters especially for stores because several of its added success criteria — Target Size (Minimum), Dragging Movements, Redundant Entry, Accessible Authentication (Minimum), Focus Not Obscured (Minimum) — read like they were written with carousels, sticky mini-carts, and checkout forms in mind. Each item in this checklist names the specific criterion it comes from, so your team can trace any finding back to the standard.
One thing this checklist is honest about, because honest coverage reporting is our whole approach: every item notes who can catch the failure. Automated checks find a subset of these issues — the machine-decidable ones, like a form control with no programmatic label. Many of the rest require a human at a keyboard, and some require testing with a screen reader. An automated scan is a fast first pass, not a finished audit, and no tool changes that.
Follow the money path
Product page, cart, checkout: the three-step journey is where accessibility failures directly cost orders. Audit those templates first, in order, before anything else on the site.
WCAG 2.2 was made for stores
Target Size (Minimum), Dragging Movements, Redundant Entry, Accessible Authentication (Minimum), and Focus Not Obscured (Minimum) all address patterns that appear constantly in e-commerce interfaces.
Keyboard first, always
The fastest meaningful test of any store: put the mouse away and buy a product using only Tab, Enter, Space, Escape, and the arrow keys. Every stage where you get stuck is a barrier.
Automated checks find a subset
Machine-checkable items — missing labels, missing alt attributes, some contrast failures — can be caught by a scanner. Focus order, meaningful announcements, and usable error recovery need manual and assistive-technology testing.
How to use this checklist
Work through one journey stage at a time, on your real templates, with the keyboard first. For each item there are three questions: what to test, what good looks like, and who can catch it if it fails — an automated check, or only a person testing manually, often with a screen reader such as NVDA (free on Windows) or VoiceOver (built into macOS and iOS).
The coverage notes matter. Where an item says a scanner can catch it, an automated check can flag the failure with confidence. Where it says manual, a scanner at best can tell you it could not confirm the good pattern — a prompt to verify, not a verdict. Treat the two kinds of finding differently and your audit stays trustworthy.
Stage 1 — Product pages: galleries, variants, add to cart
The product detail page carries the densest interaction on the site: an image gallery, variant pickers for size and color, a quantity control, and the add-to-cart button. Each is a place where a custom widget can quietly shut out keyboard and screen reader users.
- Product images describe the product, not the file. Test: read each image's alt text and ask whether a shopper who cannot see the photo learns what a sighted shopper does — cut, color, material, what is shown. Good: informative alt text on primary images; decorative flourishes marked with empty alt. Who catches it: an automated check finds a missing alt attribute (WCAG 1.1.1 Non-text Content, Level A); whether the text is actually meaningful is a human judgment.
- The gallery works without a mouse and without dragging. Test: move through thumbnails and zoom with the keyboard alone; try the swipe-style carousel. Good: every thumbnail is focusable and activatable, and any drag or swipe interaction has a single-pointer alternative such as next/previous buttons (2.1.1 Keyboard, Level A; 2.5.7 Dragging Movements, Level AA). Who catches it: manual keyboard testing — a scanner cannot operate your carousel.
- Variant selectors are real controls with real names. Test: tab to the size and color pickers; listen with a screen reader. Good: each swatch or option exposes its name ("Color: Forest Green"), its role, and its selected state, whether it is a native input or an ARIA widget (4.1.2 Name, Role, Value, Level A). A color swatch that is only a colored square conveys nothing non-visually (1.1.1). Who catches it: automated checks flag controls with no accessible name; correct roles, states, and arrow-key behavior need assistive-technology testing.
- Out-of-stock and selection state do not rely on color alone. Test: view the variant picker in grayscale. Good: unavailable options are struck through, labeled, or announced — not merely dimmed; the selected option is marked by more than a highlight (1.4.1 Use of Color, Level A). Who catches it: mostly manual; some contrast aspects are machine-checkable.
- Price and option text meet contrast minimums. Test: check body-size text at 4.5:1 against its background, large text and interface boundaries at 3:1 (1.4.3 Contrast (Minimum), Level AA). Who catches it: automated checks measure flat text-on-background reliably; text over product photography needs a human eye on the worst spot.
- Add to cart is reachable, visible, and announced. Test: tab to the add-to-cart button — is there a clearly visible focus indicator (2.4.7 Focus Visible, Level AA)? Activate it — does a screen reader user learn that the item was added, via a status message that does not steal focus (4.1.3 Status Messages, Level AA)? Good: a visible focus ring and an aria-live announcement such as "Added to cart". Who catches it: a scanner can detect that no live region exists anywhere near the interaction — as a verify-this prompt; confirming the announcement actually fires takes a screen reader.
- Quantity steppers and swatches meet minimum target size. Test: measure the plus/minus controls and swatch targets. Good: at least 24 by 24 CSS pixels, or equivalent spacing that yields the same effective target (2.5.8 Target Size (Minimum), Level AA). Who catches it: automated checks can measure rendered size in many cases; the criterion's exceptions (inline links, equivalent controls elsewhere) need human confirmation.
Stage 2 — Cart and mini-cart
Carts fail people in quieter ways than product pages. The two classic breakdowns: the mini-cart drawer that keyboard focus never enters (or never leaves), and the running total that updates silently so a screen reader user has no idea their change registered.
- Opening the mini-cart moves focus in; closing it moves focus back. Test: open the cart drawer with the keyboard; press Escape. Good: focus lands inside the drawer when it opens, stays within it while open, and returns to the trigger when it closes — no focus left stranded behind an overlay (2.1.1 Keyboard; 2.4.3 Focus Order, Level A). Who catches it: manual keyboard testing only.
- Nothing focused is hidden behind sticky UI. Test: tab through the cart page and watch whether the focused element ever disappears under a sticky header, cookie banner, or persistent checkout bar. Good: the item receiving focus is at least partially visible at all times (2.4.11 Focus Not Obscured (Minimum), Level AA — new in WCAG 2.2). Who catches it: manual keyboard testing; this depends on scroll position and layout in ways automated checks cannot fully judge.
- Quantity changes and removals are announced. Test: with a screen reader running, change a quantity and remove an item. Good: the new line total and cart count are announced through a status message without moving focus (4.1.3 Status Messages, Level AA), and the announcement says what changed. Who catches it: assistive-technology testing; a scanner can only note whether live regions are present.
- Remove, quantity, and promo-code controls are labeled and big enough. Test: check each icon-only button for an accessible name ("Remove Blue Cotton Shirt", not just a trash icon) and measure its target. Good: programmatic names tied to the specific line item (1.1.1; 4.1.2) and targets of at least 24 by 24 CSS pixels or with equivalent spacing (2.5.8). Who catches it: automated checks find unnamed buttons reliably; whether the name distinguishes between line items is a human call.
- Reordering or quantity adjustment never requires dragging. Test: if the cart supports drag-to-reorder or slider quantities, do the same task with clicks and keys alone. Good: a single-pointer, non-dragging alternative for every dragging operation (2.5.7 Dragging Movements, Level AA). Who catches it: manual testing.
- The path onward is unmistakable. Test: tab from the cart contents to the checkout button. Good: a visible focus indicator throughout (2.4.7) and a button whose text says where it goes — "Proceed to checkout", not "Continue" floating free of context (2.4.6 Headings and Labels, Level AA). Who catches it: focus-indicator presence is largely manual; vague labels are a human judgment.
Stage 3 — Checkout: forms, errors, authentication, payment
Checkout is a long form under time pressure, which makes it the stage where accessibility and conversion overlap almost perfectly. WCAG's form criteria are old and well understood; what is new in the 2.2 era is that the standard now also addresses being forced to retype information, puzzle-style logins, and tiny tap targets.
- Every field has a visible, programmatic label. Test: click each label — does its field focus? Turn on a screen reader — is each field announced by name? Good: real label elements (or equivalent programmatic association), not placeholder text that vanishes on input (3.3.2 Labels or Instructions, Level A). Who catches it: automated checks find unlabeled fields reliably — this is one of the strongest areas for scanners.
- Errors say which field failed and how to fix it. Test: submit the form empty, then with a malformed email and card date. Good: each error is identified in text next to its field and described specifically — "Enter the expiry date as MM/YY" — with focus or a summary link taking the user to the first problem (3.3.1 Error Identification, Level A; 3.3.3 Error Suggestion, Level AA). Errors indicated only by a red border fail twice: color-only and text-free. Who catches it: a scanner can flag missing error associations in static markup; the behavior on submit needs manual testing.
- Address and contact fields identify their purpose. Test: inspect the name, email, phone, and address inputs for autocomplete attributes; try browser autofill. Good: correct autocomplete tokens (given-name, email, tel, street-address, postal-code and so on) so browsers and assistive tools can fill them (1.3.5 Identify Input Purpose, Level AA). Who catches it: automated checks can verify tokens are present and valid on common field types.
- Nobody retypes what they already entered. Test: check the billing-address step when shipping is already filled; go back a step and return. Good: a "billing same as shipping" control, previously entered values preserved or offered for selection, nothing demanded twice in the same process (3.3.7 Redundant Entry, Level A — new in WCAG 2.2; exceptions exist for security-essential re-entry such as password confirmation). Who catches it: manual journey testing.
- Login and guest checkout do not depend on puzzles or memory. Test: try to check out with a password manager; look at what any CAPTCHA asks of the user. Good: paste is not blocked, password managers work, and no step relies on a cognitive test such as transcribing distorted text or solving image puzzles without an alternative (3.3.8 Accessible Authentication (Minimum), Level AA — new in WCAG 2.2). Object-recognition CAPTCHAs are permitted under the minimum criterion, but alternatives that avoid the test entirely serve more customers. Guest checkout sidesteps the whole problem for first-time buyers. Who catches it: manual testing; automated checks can at most note that a CAPTCHA or a paste-blocking script is present and prompt a review.
- Payment iframes are part of your page, whoever wrote them. Test: tab into the card fields — most stores embed them as iframes from the payment provider — and complete a payment by keyboard, then repeat with a screen reader. Good: the iframe carries a descriptive title, its internal fields are labeled, focus enters and leaves cleanly, and provider-rendered error messages are exposed to assistive technology (2.1.1; 3.3.1; 4.1.2). Who catches it: cross-origin iframes are invisible to most automated scans of your page — a scanner should say so rather than report a clean result — so this is manual territory, and worth raising with your payment provider if it fails.
- Order confirmation and totals updates are announced. Test: apply a discount code and change shipping method; listen for the new total. Good: recalculated totals announced as status messages (4.1.3), and a final review step that lets the shopper check and correct the order before committing the purchase (3.3.4 Error Prevention (Legal, Financial, Data), Level AA). Who catches it: assistive-technology testing for announcements; the presence of a review step is a straightforward manual check.
- Session time limits can be extended. Test: let a checkout session sit idle. Good: a warning before expiry with an easy way to extend, so a shopper who needs longer to complete forms is not silently logged out mid-purchase (2.2.1 Timing Adjustable, Level A). Who catches it: manual testing.
The WCAG 2.2 criteria doing the heaviest lifting here
If your store last had an accessibility pass against WCAG 2.1 or earlier, these are the additions most likely to surface new findings, with their exact numbers and levels:
- 2.4.11 Focus Not Obscured (Minimum), Level AA — the element with keyboard focus must not be entirely hidden by author-created content such as sticky bars and banners.
- 2.5.7 Dragging Movements, Level AA — any functionality that uses dragging must offer a single-pointer alternative that does not require dragging.
- 2.5.8 Target Size (Minimum), Level AA — pointer targets are at least 24 by 24 CSS pixels, unless an exception applies (equivalent target elsewhere, sufficient spacing, inline text links, user-agent default rendering, or the size being essential).
- 3.3.7 Redundant Entry, Level A — information already entered in a process is auto-populated or selectable rather than demanded again, with security-essential exceptions.
- 3.3.8 Accessible Authentication (Minimum), Level AA — no cognitive function test (memorizing, transcribing, puzzle-solving) as the only path through authentication, unless an alternative or assistance mechanism is provided; object recognition is an allowed exception at this level.
- Alongside these, two WCAG 2.1-era criteria carry much of the e-commerce load: 1.3.5 Identify Input Purpose, Level AA (autocomplete on personal-data fields) and 4.1.3 Status Messages, Level AA (announcing cart and total changes without moving focus).
Who can catch what: the honest coverage split
Automated checks are genuinely good at a specific class of problem: markup that is machine-decidably wrong. Missing form labels, missing alt attributes, unnamed buttons, invalid autocomplete tokens, many flat-color contrast failures, missing iframe titles. On a store, that class covers a real share of the findings above, and continuous scanning keeps those from regressing every time a template changes.
Everything else in this checklist has a human in the loop. Whether focus order through a mini-cart makes sense, whether a status announcement actually fires, whether an error message helps, whether alt text describes the garment — these are judgments, and an honest tool reports them as items to verify, not as passes. The practical rhythm for a store: automated checks on every deploy across the product, cart, and checkout templates; a keyboard-only purchase run on those same templates every release cycle; and a screen reader pass over the full journey on a regular schedule and after any redesign of the three stages.
Be wary of any report that presents an automated score as proof a store is accessible. A page can pass every machine check and still be impossible to buy from with a keyboard. The scan is the floor, not the ceiling.
Legal context: EAA and EN 301 549 in the EU, the ADA in the US
For stores selling to consumers in the European Union, the European Accessibility Act applies to e-commerce services explicitly — online sale of products and services is one of the named categories — and its obligations have applied since June 28, 2025. The route to conformity runs through EN 301 549, the harmonized European standard for ICT accessibility, whose web requirements incorporate WCAG 2.1 Level AA. The EAA reaches non-EU businesses that sell into the EU market, so a US or UK store shipping to European customers is in scope on the same terms as a European one. Working through a WCAG 2.2 AA checklist like this one covers the 2.1 AA material EN 301 549 points to, since WCAG versions are backwards-compatible.
In the United States, Title III of the Americans with Disabilities Act covers places of public accommodation, and courts and the Department of Justice have long applied it to the websites of businesses open to the public — retail very much included. The ADA sets no technical web standard of its own; in practice, WCAG is the benchmark referenced in case law, settlements, and DOJ guidance. E-commerce checkout flows appear regularly in web accessibility complaints for the simple reason that a barrier there blocks the site's core function.
The legal picture is a reason to do this work carefully and to document it — an accessibility statement, a record of testing, a way for customers to report barriers. It is not a reason to panic-buy a badge: no product or overlay can make those obligations disappear, and the durable position is a store that people with disabilities can actually use.
Keeping a store accessible over time
E-commerce sites change faster than almost any other kind of website: seasonal campaigns, new payment methods, third-party apps, theme updates. Each change can reintroduce a barrier that was fixed last quarter, so accessibility has to run as a process rather than a project.
- Scan the product, cart, and checkout templates continuously, and treat any new machine-detectable failure there as a release blocker.
- Re-run the keyboard-only purchase after every theme update, app installation, or checkout change — third-party code is the most common source of regressions.
- When you add a payment provider or express-checkout button, test its embedded UI with a keyboard and screen reader before launch, and raise failures with the provider.
- Publish an accessibility statement with a working contact channel, and route reported barriers to the team that owns the template, with the same priority as a checkout bug — because that is what they are.
- Keep records of what you tested, what you found, and what you fixed. Documentation of ongoing work is useful under both the EAA's conformity expectations and in any ADA-related inquiry.
Frequently asked questions
Can an automated scanner tell me whether my store is accessible?
No single tool can. Automated checks reliably find machine-decidable failures — unlabeled fields, missing alt attributes, unnamed buttons, many contrast issues — and they are excellent at catching regressions continuously. But core store interactions such as mini-cart focus handling, live-region announcements, and payment-iframe behavior require manual keyboard testing and screen reader testing. Use automated scanning as the always-on first layer and schedule human testing of the purchase journey on top of it.
Do WCAG requirements apply to my payment provider's embedded fields?
From your customer's perspective there is only one checkout, so barriers inside an embedded payment iframe are barriers in your store. You control some of it directly — the iframe title, the surrounding labels, focus handling into and out of the frame — and for the rest you are choosing a provider. Test embedded payment UIs by keyboard and screen reader before adopting them, and report failures to the provider; most major providers document the accessibility of their hosted fields.
Which WCAG version should an online store target?
Target WCAG 2.2 Level AA. It is the current version, it contains everything in 2.1 AA — which is what EN 301 549 and most legal references point to — and its added criteria (Target Size, Dragging Movements, Redundant Entry, Accessible Authentication, Focus Not Obscured) map directly onto common e-commerce patterns. Meeting 2.2 AA automatically satisfies references to 2.1 or 2.0 AA because versions are backwards-compatible.
Is a CAPTCHA at checkout or login a WCAG failure?
It depends on what the CAPTCHA demands. Under WCAG 2.2's 3.3.8 Accessible Authentication (Minimum), an authentication step may not rely on a cognitive function test — transcribing distorted characters, remembering a code — unless there is an alternative or assistance; object-recognition tests are an allowed exception at this level. Separately, 1.1.1 has always required text alternatives and alternative forms for CAPTCHAs. The practical answer for stores: prefer mechanisms that avoid user-facing puzzles entirely, and offer guest checkout so authentication is never the price of a first purchase.
We sell from the US into the EU — does the European Accessibility Act really apply to us?
If you sell covered services, including e-commerce, to consumers in the EU, the EAA can apply regardless of where your business is based — selling into the EU market is what triggers the obligation. Its requirements have applied since June 28, 2025. Conformity for web content is demonstrated through EN 301 549, which incorporates WCAG 2.1 Level AA, so the same checklist work serves both your EU obligations and your position under US ADA case law.
This article is provided for general information about accessibility regulations and standards. It is not legal advice — consult a qualified professional about your specific compliance obligations.