An accessibility statement for a store needs to do everything a general accessibility statement does, name a conformance target, disclose known limitations, give a working contact channel, and then go further into the one part of the site that carries the most legal exposure and the most day-to-day impact on whether a disabled customer can actually complete a purchase: the checkout flow. A statement that only speaks in general terms about “the website” while saying nothing about cart, forms, or payment is missing the part of an online store that matters most.
Why Checkout Is the Highest-Risk Part of a Store
Retail and ecommerce sites are consistently the most frequently named category in ADA Title III website lawsuits, and the specific features plaintiffs’ attorneys cite most often are exactly the checkout-adjacent ones: unlabeled form fields, add-to-cart controls that only respond to a mouse, and error messages that fail to explain what went wrong on a payment form. A homepage with a missing alt tag is a real accessibility gap, but a checkout a screen-reader user cannot complete is the difference between a browsing customer and a lost sale, which is exactly why this is the part of the statement worth the most specificity.
WCAG Criteria That Apply Directly to Checkout
WCAG 2.1 and 2.2 are general-purpose standards, but a specific handful of success criteria map directly onto what happens between “add to cart” and “order confirmed.”
WCAG Success Criteria Applied to Checkout
| What It Requires | Checkout Example | |
|---|---|---|
| 2.1.1 Keyboard | Works without a mouse | Cart, quantity steppers, not drag-only |
| 3.3.1 Error Identification | Errors described in text | Decline reason stated, not just red |
| 3.3.2 Labels or Instructions | Every field has a real label | Card, expiry, CVV have real labels |
| 3.3.4 Error Prevention | Orders reviewable before final submit | An order review step before Place Order |
| 4.1.2 Name, Role, Value | Widgets expose state to assistive tech | Custom dropdowns announce their value |
3.3.4, Error Prevention for legal, financial, or data transactions, is the criterion most specific to commerce and the one most often missing from a general-purpose site audit that was not written with a store in mind. It requires that a transaction can be reviewed and corrected, or reversed, before it becomes final, which in practice means an order summary or confirmation step between “enter payment details” and the charge actually going through, available to every user regardless of how they navigate the page.
Where a Store’s Statement Should Get Specific
The limitations section of a store’s accessibility statement is the part most tempted to stay vague, and that is the opposite of what makes it useful. Name the actual checkout components that have not been tested or remediated: a third-party payment widget embedded via iframe that the store does not control, a size or color selector implemented as unlabeled swatches, a quantity stepper that only responds to a click and not a keyboard, a promotional popup that traps focus during checkout. Each of these is common in real storefronts, and naming the specific ones that apply is what turns the statement from a generic disclaimer into evidence the store actually audited its own checkout.
Third-party payment widgets deserve their own line in the statement specifically because they are the piece of checkout a store typically does not build or control. A store using an embedded payment iframe from a processor is depending on that processor’s own accessibility work, and the statement should say so plainly, rather than implying the store tested something it structurally cannot audit past the iframe boundary. Naming that limitation is more defensible than silence, and it is accurate: a store cannot certify what it cannot inspect.
Why This Still Is Not a Substitute for Fixing Checkout
Everything true of a general accessibility statement is still true here, and more so given the stakes: publishing a statement documents a state of testing, it does not create an accessible checkout. A store with a well-written statement listing five known checkout gaps and no remediation plan is not protected by having written the statement; if anything, a specific statement makes the gap harder to argue was unknown. The statement is the disclosure layer sitting on top of real remediation work, prioritized by what blocks a transaction outright (an unlabeled required field, a keyboard trap) over what is a lower-severity gap (a missing alt tag on a product thumbnail), and revisited every time checkout changes, not just on a fixed annual schedule.
Our Accessibility Statement generator prompts for a conformance target, limitations, and contact details the way any accessibility statement needs; for the general version of this document covering a non-commerce site, see how to write an accessibility statement that meets ADA and WCAG expectations, which this guide builds on with the checkout-specific detail a store needs on top.
A store’s accessibility statement earns its keep by being specific about the one flow that decides whether a disabled customer can actually buy something: name the WCAG target, list the real checkout gaps by component, and keep updating the statement every time the cart, forms, or payment step changes underneath it.
