The Most Common WCAG 2.1 AA Issues in E-Commerce Checkout & Cart Flows

Checkout is the one flow on an e-commerce site where accessibility failures cost money directly — a customer who can’t complete a purchase doesn’t file a complaint, they just leave. Below are the nine WCAG 2.1 AA failures we see most often in cart and checkout UI specifically, each mapped to the exact success criterion it violates, with a concrete fix.

Quick answer: the checkout-specific WCAG 2.1 AA failures that block real customers most often are unlabeled form fields, insufficient color contrast, missing autocomplete attributes on payment/address fields, form errors that aren’t announced to screen readers, no way to correct or confirm a purchase before it’s final, keyboard traps in cart drawers, silent cart-count updates, invisible focus indicators, and missing alt text on cart product thumbnails.

This article covers technical accessibility standards, not legal advice — it doesn’t tell you whether your specific site carries legal risk, only what WCAG 2.1 AA requires and how to meet it.

1. Unlabeled or mislabeled form fields

The problem: a checkout field that relies on placeholder text or nearby visual positioning instead of a real, programmatically associated <label>. Placeholder text disappears the moment a user starts typing, and screen readers may not announce it at all. This is one of the most common accessibility failures on the web generally — the WebAIM Million 2026 report found unlabeled form inputs on 51% of the one million home pages it scanned.

The fix: every input gets a <label for="id"> (or aria-labelledby) tied to its field’s id. If you need placeholder-style compact layouts, keep the label visible or use aria-label as a last resort — never a placeholder alone.

WCAG reference: 3.3.2 Labels or Instructions (A), 1.3.1 Info and Relationships (A).

2. Insufficient color contrast on price, discount, and button text

The problem: light-gray “was $49.99” strikethrough text, low-contrast disabled-looking “Place order” buttons, or thin-weight sale-price text that fails the 4.5:1 (normal text) or 3:1 (large text/UI components) contrast ratio. Low-contrast text was the single most common failure category in the WebAIM Million analysis, appearing on 83.9% of scanned home pages.

The fix: check every text/background pair used in cart summaries and checkout buttons with a contrast calculator, not by eye. Don’t rely on color alone to signal “sale,” “sold out,” or “selected” — pair it with text or an icon.

WCAG reference: 1.4.3 Contrast (Minimum) (AA).

3. Missing autocomplete on payment and address fields

The problem: checkout name, address, and card-number fields without an autocomplete attribute (or with it explicitly disabled). This forces every customer to hand-type information the browser or a password manager could fill automatically, which disproportionately burdens users with motor or cognitive disabilities — and it’s a checkout abandonment risk for everyone else too.

The fix: use the standard HTML autocomplete tokens — autocomplete="cc-number", "given-name", "family-name", "street-address", "postal-code", and so on — on every field that collects that kind of user data. Don’t disable autofill on the theory that it’s more secure; modern password managers and browser payment autofill are not the security risk that reasoning assumes.

WCAG reference: 1.3.5 Identify Input Purpose (AA).

4. Form errors that only appear visually

The problem: a rejected checkout submission that highlights bad fields in red but doesn’t move focus to the error or announce it. A sighted user sees the red border; a screen reader user re-submits into the same wall and may conclude the page is broken.

The fix: identify the specific field in error, describe the problem in text near the field, and move focus (or use an announced summary) so assistive technology users know something went wrong and what to do about it.

WCAG reference: 3.3.1 Error Identification (A).

5. No suggestion for how to fix the error

The problem: “Invalid input” with no indication of what’s actually wrong — wrong format, missing required value, or a value outside an allowed range.

The fix: where the correction is knowable, say so: “Enter a 5-digit ZIP code,” not “Invalid ZIP.” Skip suggestions only where offering one would create a security risk (e.g., don’t hint at the correct card number).

WCAG reference: 3.3.3 Error Suggestion (AA).

6. No confirmation step before an irreversible purchase

The problem: a single “Place order” click that immediately charges the card with no review step, and no way to correct a wrong quantity or shipping address before the charge goes through. WCAG explicitly calls out financial transactions as needing this protection, precisely because the consequence of a mistake is costly and can’t be undone.

The fix: show an order summary the customer can review and edit before final submission, or make the order reversible/cancelable for a short window after submission.

WCAG reference: 3.3.4 Error Prevention (Legal, Financial, Data) (AA).

7. Keyboard traps in cart drawers and modals

The problem: a slide-out cart drawer or “add to cart” confirmation modal that a keyboard user can tab into but can’t tab back out of — often inherited from a third-party cart widget that was never tested without a mouse.

The fix: on open, move focus into the drawer; while open, keep Tab/Shift+Tab cycling inside it; always provide an Escape/close control; on close, return focus to the element that opened it.

WCAG reference: 2.1.2 No Keyboard Trap (A), 2.4.3 Focus Order (A).

8. Cart updates that are silent to screen readers

The problem: “Added to cart” or a cart-count badge that updates visually with no announcement, so a screen reader user has no idea whether the click registered.

The fix: use a live region (role="status" with its implicit polite aria-live) that’s present in the DOM from page load, not injected at the moment of the update — screen readers frequently miss announcements from elements that are added and populated in the same step.

WCAG reference: 4.1.3 Status Messages (AA).

9. Invisible focus indicators and missing alt text on cart images

Two smaller but common issues worth checking in the same pass: custom-styled buttons that strip the browser’s default focus outline (outline: none) without providing a visible replacement, leaving keyboard users unable to see where they are; and cart-line-item product thumbnails with no alt text, or generic alt text like “product image” that tells a screen reader user nothing about what’s actually in their cart.

The fix: keep a clearly visible focus style on every interactive element (2px+ outline with sufficient contrast against its background), and give each cart thumbnail real alt text — the product name is usually enough, since the name is already visible as text next to it, so a short alt="Product Name" avoids duplicating the full description unnecessarily.

WCAG reference: 2.4.7 Focus Visible (AA), 1.1.1 Non-Text Content (A).

Where to start

None of these require a redesign. Labels, autocomplete tokens, contrast fixes, and alt text are copy-and-attribute changes; focus management and live regions are a few hours of front-end work per component. Automated scanners (axe, WAVE, Lighthouse) will catch most of issues 1, 2, 3, and 9 — a person still needs to check focus order, keyboard traps, and whether status messages are actually announced, since those require operating the flow by keyboard and screen reader, not just reading the DOM.

FAQ

Do these WCAG issues apply to the whole checkout flow, or just one page? WCAG conformance applies to every page in a process — if checkout spans cart, shipping, payment, and confirmation pages, all of them need to conform for the flow as a whole to meet the standard, per the W3C WCAG 2.1 spec.

Is WCAG 2.1 AA legally required for e-commerce sites? The Department of Justice has stated that the ADA applies to business websites and consistently points to WCAG 2.1 AA as the reference standard in guidance and enforcement, but as of this writing there is no DOJ-issued binding technical rule under Title III specifically for private businesses (that’s distinct from the 2024 Title II rule, which applies only to state and local government sites). See the DOJ’s own guidance page for the current federal position. This is general information, not legal advice — talk to a qualified attorney about your specific compliance obligations.

Will fixing these nine issues make a checkout flow fully WCAG 2.1 AA compliant? No — this list covers the failures most concentrated in checkout/cart UI specifically, not the full WCAG 2.1 AA success criteria. A full audit checks the whole standard against the whole flow.

---

This is educational content about technical accessibility standards, not legal advice. Meeting WCAG 2.1 AA does not guarantee legal compliance with the ADA or any other law, and nothing here should be read as a compliance guarantee. Consult qualified counsel for legal risk questions.