Accessible checkout: 7 common mistakes

Why the checkout in particular is critical

The checkout is revenue-critical, form-heavy and multi-step — exactly where accessibility errors prevent a purchase entirely. Under the BFSG the ordering process in electronic commerce clearly falls within scope (see “BFSG: Who is affected?”). A barrier here is not cosmetic — it can abort the sale.

1. Form fields without a real label

Fields that only have a placeholder instead of a label lose their caption as soon as you type — and screen readers do not announce them reliably. Fix: every field gets a visible, programmatically associated <label>. A placeholder is not a label (1.3.1, 3.3.2).

2. Error messages by colour alone

A red-bordered field alone tells screen-reader users and people with colour vision deficiency nothing. Fix: output errors as text, associate them with the field (e.g. via aria-describedby), give a correction hint and announce the message — not by colour alone (1.4.1, 3.3.1, 3.3.3).

3. Controls that are not keyboard-operable

Custom dropdowns, date pickers, quantity steppers or embedded payment widgets that only work with the mouse lock out keyboard users. Fix: use native controls or equip custom components with correct ARIA and full keyboard operation — and play through the whole flow with Tab, Enter and Escape (2.1.1).

4. Focus is invisible or illogical

Without a visible focus indicator you do not know where you are; if the focus jumps illogically between steps or is not managed for a dialog, you lose the thread. Fix: clearly visible focus, logical focus order, set and return focus deliberately at step and dialog changes (2.4.3, 2.4.7, 2.4.11).

5. Click targets that are too small

Tiny quantity buttons, checkboxes or “remove” icons are hard to hit for people with motor impairments or on a touchscreen. Fix: make interactive targets at least 24×24 CSS pixels or leave sufficient spacing (2.5.8, new in WCAG 2.2).

6. Captcha or login as an insurmountable hurdle

An image captcha without an alternative, a login that demands a cognitive test, or fields that block paste and password managers exclude users. Fix: accessible authentication — allow paste and password managers, offer non-cognitive alternatives (3.3.8, new in WCAG 2.2).

7. Dynamic updates are not announced

When the subtotal, shipping cost or a redeemed voucher update silently, screen-reader users do not notice the change. Fix: announce such status changes via aria-live regions, without moving the focus (4.1.3).

How to check your checkout

Put the mouse aside and complete a purchase entirely with the keyboard; then repeat it with a screen reader. WCAG 2.2 AA serves as the grid — the points are listed by the “WCAG 2.2 AA checklist”. Because the checkout sits behind steps and in part behind a login, it is exactly the compliance-critical flow an audit must cover end to end — more on this in “What does an accessibility audit cost?”.