The $180 Cart That Never Closed
She's been shopping for twenty minutes. Four items in the cart, free shipping threshold cleared, a promo code ready to go. She reaches checkout using a screen reader, tabs into the payment section, and the trouble starts immediately.
The credit card number field announces as "edit text, blank." So does the expiration date. So does the CVV. No names, no context, just three identical blank fields in a row where a sighted shopper would see clear labels sitting right above each box.
She guesses, types the promo code into what she hopes is the right field, and hits apply. Somewhere above the fold, a red line of text appears: the code is invalid. She never hears about it. Nothing announces. She submits the order anyway, gets a silent rejection, and after two more tries, closes the tab.
The store loses $180. It never shows up as a bug report or a support ticket — it shows up as an abandoned cart in analytics, indistinguishable from someone who just changed their mind. That's what makes checkout accessibility so easy to ignore and so expensive to keep ignoring.
Why Checkout Is the Highest-Stakes Page on the Site
Every other page on an ecommerce site is optional. A visitor can skip the blog, skim the about page, never touch the size guide. Checkout is not optional. It's the one flow every single paying customer has to complete, no exceptions, and it usually carries the highest concentration of forms, dynamic updates, and third-party embedded widgets anywhere on the site — payment processors, address autocomplete, promo code validation, buy-now-pay-later modals.
That concentration is exactly why checkout is disproportionately represented in both accessibility complaints and lost revenue. A single broken form field on a content page annoys one visitor. A single broken form field at checkout blocks every transaction that flows through it.
3.3.4 Error Prevention: The Rule Built for This Exact Page
3.3.4 Error Prevention (Legal, Financial, Data), Level AA, is written almost as if checkout were the intended target. It applies to any submission that's a legal commitment or a financial transaction, and it requires one of three protections: the process is reversible, submissions are checked for errors with a chance to correct them, or the user gets a confirmation step before the transaction finalizes.
A checkout that charges a card the instant "Place Order" is clicked, with no review screen showing the final total, items, and shipping address first, is a direct failure of this criterion. It's also a UX failure independent of accessibility — everyone benefits from seeing what they're about to pay before the charge goes through, not after.
The fix is a genuine review step: a page or panel that lays out the order contents, shipping method, address, and final total, with a clear path back to edit anything before the final confirm.
1.3.5 Identify Input Purpose: Let the Browser Help
1.3.5 Identify Input Purpose, Level AA, requires that common input fields — name, email, address, and in most implementations, credit card number — have a programmatically determinable purpose. In practice, that means the HTML autocomplete attribute is set correctly: autocomplete="cc-number", autocomplete="shipping street-address", autocomplete="email", and so on.
This one criterion does double duty. It satisfies WCAG, and it's also what lets browsers and password managers auto-fill fields correctly. A field missing this attribute doesn't just fail an audit — it forces every returning customer, disabled or not, to retype information their browser already has saved.
4.1.3 Status Messages: The Silent Error That Killed the Sale
Go back to the opening story. The promo code error wasn't invisible — it was right there on the screen, in red text, above the fold. It just wasn't announced. That's the exact gap 4.1.3 Status Messages, Level AA, closes.
This criterion requires that important status changes — added to cart, promo code applied or rejected, form error appeared, shipping cost updated when a new address is entered — be communicated to assistive technology without requiring the user to move focus and go looking for what changed. The standard mechanism is an ARIA live region: aria-live="polite" on the container holding the message, so when its content updates, a screen reader announces it automatically.
Without that live region, a sighted user sees the red text shift into view and reads it in half a second. A screen reader user gets nothing. The visual fix and the accessible fix aren't in conflict here — the visual message just needs a wire connected to it.
3.3.7 Redundant Entry: Stop Asking Twice
WCAG 2.2 added 3.3.7 Redundant Entry, Level AA, and it maps onto one of the most common checkout annoyances there is: typing the same address into two separate forms because billing and shipping happen to match.
The requirement is simple — if information has already been entered once earlier in the same process, don't force the user to re-enter it, unless it's essential to confirm or the original entry is no longer valid. A "same as shipping" checkbox that actually copies the address data satisfies this. A checkbox that's purely decorative and still requires manual retyping does not, and it costs both accessibility compliance and a few extra seconds of friction for every customer who checks that box.
The Third-Party Blind Spot
Here's the part that catches even careful teams off guard: a business can rebuild its own templates perfectly and still fail at checkout, because the payment processor's embedded iframe, the address-lookup widget, or the financing modal has its own unlabeled fields or its own keyboard trap — and none of it is directly under the site owner's control.
This is a real, common failure pattern. A store's product pages, cart, and shipping form can be fully accessible while the actual credit card entry widget, licensed from a third-party payment provider, silently breaks the whole flow. Auditing checkout means testing the entire assembled experience, not just the code the store's own developers wrote — and it means asking vendors directly whether their embedded widgets have been tested for keyboard access and screen reader compatibility.
The Practical Checkout Audit Checklist
Run through this list against a live checkout, not just the design mockups:
- Every field, including payment fields inside third-party widgets, has a real associated label and the correct
autocompletevalue - Every error is shown visually and announced through a live region — never one without the other
- A review or confirmation step exists before the final charge goes through
- Cart, quantity, and price updates are announced automatically when they change
- The entire flow — including custom quantity steppers and address autocomplete dropdowns — is completable using a keyboard alone, with no trap at any step
- "Same as shipping" and similar shortcuts actually copy the data instead of just hiding a field
The Conversion Case Is the Compliance Case
This is worth stating plainly, because it changes how a business should prioritize this work: unclear errors, silent status updates, and unlabeled fields don't only fail an accessibility audit — they show up in ordinary conversion-rate-optimization data as cart abandonment. A shopper who can't tell why their promo code failed gives up regardless of whether they're using a screen reader. Fixing checkout for 3.3.4, 1.3.5, and 4.1.3 compliance is, in most stores, the identical work to fixing the friction points a CRO consultant would flag independently.
That's rare. Most compliance work costs something with no visible upside beyond avoiding a complaint. Checkout accessibility pays for itself twice — once in reduced legal exposure, and once in every recovered sale that would otherwise have quietly disappeared into an abandoned-cart report with no explanation attached.
The shopper in the opening story didn't leave because she didn't want the product. She left because the store never gave her a way to finish buying it. That's a fixable, testable, specific set of gaps — not a mystery.
If you want to know exactly where your own checkout stands against 3.3.4, 1.3.5, 4.1.3, and the rest of this list, see how we can help before your next abandoned cart is one you never explain.