Accessible checkout: the last stretch where orders are lost

The checkout concentrates the most demanding WCAG 2.2 success criteria, because almost everything here is forms, state changes and legally binding input. Section 3.3 (input assistance) is decisive: labels or instructions (3.3.2), error identification (3.3.1), error suggestion (3.3.3) and error prevention for legal commitments (3.3.4). Two criteria newly introduced by WCAG 2.2 hit the ordering process directly: Redundant Entry (3.3.7) prohibits asking again for data already provided without good reason, and Accessible Authentication (3.3.8) rules out cognitive function tests during sign-in, such as image puzzles without an alternative (source: W3C WCAG 2.2). On top of that come the general requirements for keyboard operability (2.1.1), visible focus (2.4.7) and the new rule that the focused area must not be obscured by sticky elements (2.4.11).

In many shops there is a hurdle before the payment flow proper that WCAG 2.2 addresses explicitly for the first time: signing in. Success criterion 3.3.8 (Accessible Authentication, level AA) requires that no authentication step depends on a cognitive function test unless an alternative is offered. Image puzzles, arithmetic tasks and transcribing distorted character strings all fall under this. Equally problematic is blocking paste in the password field, because that disables password managers. We encounter both regularly in audits — and both can be fixed with manageable effort.

In practice this means: password fields allow paste and autofill and carry the appropriate autocomplete values. Two-factor codes are supported via autocomplete too, so they do not have to be typed out. Where spam protection is necessary, we rely on methods that require no cognitive effort — server-side checks or invisible methods with a documented alternative. And because the fastest accessible sign-in is the one that does not happen, we recommend a full guest checkout without forcing account creation. Where an account is mandatory, registration itself must meet the criteria. The article on accessible authentication describes the options in detail.

Payment processing is the area where shop operators depend most heavily on third parties. Embedded payment forms can bring their own accessibility problems: iframes without an accessible title, card fields without labels, verification methods that cannot be solved with a screen reader. Legally this does not release you: the BFSG addresses the provider of the service, and towards your customers that is you. We therefore test the accessibility of the integrated providers, document barriers outside your control and, where necessary, recommend alternative payment routes.

Where possible we configure payment providers for maximum accessibility: correct labelling of the embedded fields, accessible error handling and accessible confirmation pages. If a limitation remains, it belongs transparently in the accessibility statement — together with an alternative route to concluding the contract, by phone or email for instance. This documentation is not an admission but exactly what BFSG Section 14 requires. How a solid statement is structured is covered on the page about the accessibility statement.

When cart abandonment is discussed, the talk is usually about shipping costs, delivery times or missing payment methods. For people who depend on assistive technology the reason often sits one level below: the form does not say what is wrong. The order button cannot be reached by keyboard. The time limit in the payment step expires before the entry is finished. Around 7.8 million (Federal Statistical Office, 2023) people in Germany have a recognized severe disability, plus millions with temporary or age-related limitations. This group does not abandon because it does not want to buy, but because it cannot.

The second effect is broader: a checkout that works without a mouse, with enlarged text and with clear error messages works better for everyone else too. Sensible autocomplete attributes save every customer typing. A comprehensible error message instead of a bare validation warning prevents support enquiries. A summary showing all details before submission reduces mis-orders and returns. Accessibility in the checkout is therefore rarely only a compliance expense; it is at the same time an investment in the quality of the order flow.

For that state to last, the team needs to know what matters. Our training shows development and editorial teams how to build new checkout features accessibly from the outset. For ongoing assurance after implementation there is BFSG monitoring, which reports regressions after updates before they cost orders.