Accessible Checkout for Shops

The foundation of an accessible checkout is correctly labeled form fields. Every input field must have an associated <label> element that is programmatically linked to the field. Placeholder text alone is not sufficient, as it disappears when typing and is not consistently recognized as a label by screen readers. The WebAIM Million Report (2024) identifies missing form labels as the third largest accessibility problem with 48.6% (WebAIM Million Report, 2024) of all tested home pages.

Required fields must be marked both visually and programmatically. A red asterisk alone is not enough: the attribute aria-required="true" or the HTML attribute required informs assistive technologies that the field must be filled in. Additionally, a note at the beginning of the form should explain the meaning of the required field marking.

Autocomplete attributes per the HTML standard are another important building block. Fields like autocomplete="given-name", autocomplete="family-name", autocomplete="street-address" and autocomplete="postal-code" enable browsers and assistive technologies to automatically insert stored data. This significantly reduces input burden, especially for users who have difficulty with manual text entry. The accessible shop implements these attributes for all relevant fields.

Address forms in checkout present special accessibility challenges. A typical address form contains six to ten fields that must be logically grouped and labeled. The HTML elements <fieldset> and <legend> group related fields together: one fieldset for the billing address, another for the shipping address. Screen readers read the legend when the user navigates into the group, providing context.

A particularly common problem is the ZIP code field: many shops accept only certain formats but do not clearly communicate the format requirement. An accessible ZIP code field provides the expected format in help text below the field, linked to the field via aria-describedby. For international shops supporting different address formats, the form must dynamically respond to country selection and adjust the field structure accordingly.

The option to use the billing address as the shipping address directly fulfills WCAG 2.2 criterion 3.3.7 (Redundant Entry). Implementation uses a checkbox with a clear label that, when activated, automatically populates the shipping address fields and optionally hides them visually. Screen readers must be correctly informed about the checkbox state and its effect on the remaining fields.

Multi-step checkouts use progress indicators to show users where they are in the process. For sighted users, this is often a visual bar or a step sequence with numbered circles. For screen reader users, this information must be programmatically available. The attribute aria-current="step" marks the current step, while an overview of all steps can be implemented as an ordered list.

When switching between steps, focus must be correctly managed. When the user completes the address step and switches to the payment step, focus should be set to the heading or first form field block of the new step. A page change without focus management means screen reader users don't know where they are, and keyboard users must navigate from the beginning of the page.

An accessible progress indicator also communicates which steps are already completed, whether the user can return to an earlier step and how many steps remain. Completed steps can be implemented as links enabling return. The total number of steps is announced upon entering the checkout, for example: Step 2 of 4.

Every single step in the checkout must be fully keyboard-operable. This means: form fields are reachable via Tab, radio groups navigable via arrow keys, checkboxes activatable via Space and buttons triggerable via Enter and Space. Modal dialogs, as used for address validation or payment confirmation, must implement a focus trap and be closable via Escape.

A common problem is custom dropdowns for country selection that visually look like native select elements but do not offer the same keyboard operability. The recommendation: use native HTML elements wherever possible. When custom widgets are necessary, they must implement the complete keyboard interaction pattern of the native counterpart, including type-ahead search for long lists.

Skip links at the beginning of each checkout step allow keyboard users to jump directly to the relevant form without having to traverse header and navigation again. For shops with extensive headers, this saves considerable time and reduces frustration. Accessible web development implements skip links as standard on every page.

Mobile checkout places additional accessibility requirements. Touch targets must be at least 24x24 CSS pixels per WCAG 2.2 (criterion 2.5.8). On mobile devices, where finger operation is less precise than mouse operation, a target size of 44x44 pixels or more is recommended. Buttons, checkboxes and radio buttons in checkout must meet these minimum sizes.

The input keyboard on mobile devices can be controlled via the inputmode attribute: inputmode="numeric" for ZIP code and phone number, inputmode="email" for email addresses, inputmode="tel" for phone numbers. This significantly facilitates input and reduces errors. Combined with the type attribute and autocomplete values, this creates a mobile checkout that minimizes input burden. According to the Baymard Institute, 17 percent (Baymard Institute, 2025) of surveyed US online shoppers have abandoned an order because the checkout was too long or complicated – suitable on-screen keyboards and autocomplete reduce exactly this effort.

Zoom must be fully supported in mobile checkout. The meta viewport directive user-scalable=no blocks zooming and violates WCAG 1.4.4. Form fields with a font size below 16 pixels trigger automatic zoom on iOS, disrupting the user experience. The solution: set all input fields to at least 16 pixel font size and leave the user in control of the zoom level.