Accessible checkout: what customers must be able to do without a mouse
The customer has navigated the catalogue, selected a product and added it to the basket. They then complete a form, press “Place order” and nothing happens. There is an error somewhere, but they cannot see it and their screen reader has not announced it. They try again, still receive no response and leave. All you see is an abandoned basket.
Checkout is one of the most sensitive parts of an online shop. The customer must complete several connected steps, and a barrier can cause them to abandon the purchase. It therefore has a high priority in an accessibility assessment.
Common checkout problems and how to address them
Every field must have a label that is programmatically associated with it, not merely text displayed visually beside it. Without one, a screen reader announces “text field”, leaving the customer unsure whether to enter their name, town or house number.
Common errors we find include:
- a label replaced only by placeholder text inside the field—the placeholder disappears when typing begins, leaving nothing to read when the completed form is reviewed;
- a field identified only by an icon with no text alternative;
- a required field indicated only by an asterisk or colour, with no corresponding information in the code;
- help text beneath a field, such as a telephone-number format or password character count, that is not associated with the field, so the screen reader may not announce it when the field receives focus.
Errors need to be announced, not merely coloured
This is a serious type of barrier in checkout. An error message may be present in the HTML but not programmatically associated with the field or announced by the screen reader. The user then sees or hears only part of the information needed to correct the input.
An accessible form must announce the error, associate it with the relevant field and allow the user to reach it easily. Depending on the design, moving focus to an error summary or to the first invalid field can help; there is no single universal rule for every form. The message should explain what is wrong and how to correct it—“Invalid input” is not enough. The error must not be communicated through colour alone: a customer with low vision may not see a low-contrast red border.
Element order and time limits
The order in which focus moves with the Tab key must preserve the meaning and operability of the content; it does not have to mirror the visual layout mechanically. In a dynamic checkout, steps render progressively, sections expand and focus may remain where an element no longer exists. When a genuinely modal window opens—for example, to select a branch or confirm an address—focus moves inside it and remains there. The window must offer a keyboard-accessible way to close it; Escape is a conventional option, not the only permissible mechanism.
Time limits are another common barrier. A basket reservation, payment-session expiry or automatic sign-out may have a valid purpose, but a customer using a keyboard or screen reader may need more time. Unless an exception permitted by the applicable WCAG criterion applies, the user must be warned about the limit and given an opportunity to turn it off, adjust it or extend it.
Selecting delivery and payment
The purchase can fail at this point because custom controls have been built instead of standard radio buttons. The result may be a set of tiles with carrier logos that cannot receive focus or cannot be selected with a keyboard once focused.
We verify that every option can be selected with a keyboard, that the screen reader announces its name and price, that the currently selected option is clear, and that the customer is informed about what has been recalculated after changing delivery. We also check the payment step, including embedded payment-gateway frames—they are part of your purchase journey regardless of who supplied them.
What an accessible checkout gives you
We test the machine-testable parts of checkout automatically across real states—after sign-in, after a modal window opens or after a form is submitted. A person supplements this with keyboard scenarios and a review of whether error messages make sense. This combination helps detect errors following a change without promising complete coverage.
The output is a report mapped to the relevant WCAG and EN 301 549 criteria. We use WCAG 2.2 as the more current professional target; for a legal or contractual assessment, the required version of the standard must be confirmed. The report provides technical evidence, not an automatic legal guarantee of compliance.
Next step
If you suspect that checkout barriers are preventing customers from completing purchases, we can agree an appropriate scope for automated and manual assessment during a no-obligation consultation.