Accessible forms and checkout: labels, errors and autocomplete

An accessible form has a visible label tied to every field in the code, tells people before they start what format and which fields are required, explains each error in words next to the field, and lets the browser fill in personal details through the autocomplete attribute (WCAG 1.3.5). Checkout adds three more needs: do not make people type the same address twice, let them review before paying, and announce changes such as an updated total.⁴

Forms are where accessibility problems cost sales directly. WebAIM's 2026 scan of the top million home pages found missing form input labels on 51% of them.⁹ A customer who cannot tell which field is which, or cannot find out why a payment form was rejected, leaves.

The WCAG criteria that apply to forms

The levels and wording are from WCAG 2.2.⁴

Labels: visible, and connected in the code

W3C's forms tutorial says to identify each control with a label element, and that the label's for attribute must exactly match the field's id.² That connection is what makes a screen reader announce "Email" when focus lands in the field, and it makes the label clickable, which helps anyone with limited dexterity.¹

• Placeholder text is not a label. It disappears as soon as someone types and is often too faint to read. Keep a visible label above the field.
• Hidden labels must stay in the code. If a design really has no room for a visible label, such as a search box next to a search button, hide the label with a visually hidden CSS class. W3C warns that display: none or visibility: hidden hides it from screen readers too.²
• Avoid the title attribute as a label. W3C calls it less reliable and not recommended.²
• Group related choices. Radio buttons for delivery options or a set of checkboxes belong in a fieldset with a legend, so a screen reader announces "Delivery method" before "Standard" and "Express".¹

Autocomplete: WCAG 1.3.5 in practice

Criterion 1.3.5 asks that the purpose of each field collecting information about the user can be programmatically determined. The sufficient technique in HTML is the autocomplete attribute with the standard values.⁵ W3C explains why: browsers can fill in details for people with memory or language difficulties, people with motor impairments type less, and assistive technology can add familiar icons to fields.⁵

The values come from the HTML standard. The ones a checkout needs most are:⁶

• name, or given-name and family-name
• email and tel
• street-address, or address-line1 and address-line2
• address-level2 (town or city), address-level1 (state or county), postal-code, country
• cc-name, cc-number, cc-exp, cc-csc for card fields
• username, current-password, new-password and one-time-code for accounts

Put shipping or billing in front to tell the two addresses apart, for example autocomplete="shipping postal-code".⁶ W3C names incorrect autocomplete values as a failure of 1.3.5, so a wrong value is worse than leaving it out.⁵ The criterion only covers information about the customer; a gift message or a coupon code field does not need a value.⁵

Errors: say what is wrong, where, and how to fix it

W3C's guidance on form notifications combines several techniques:³

1. An error summary above the form after a failed submit, with a heading, the number of errors, and a link to each field in error.
2. A message next to each field, connected to it with aria-describedby so a screen reader reads it with the label.
3. Focus moved to the summary or the first field with an error, so a keyboard or screen reader user is not left at the submit button wondering what happened.
4. The page title updated with the error count where the page reloads, because it is the first thing a screen reader announces.

Write the message as an instruction: "Enter a postcode in the format SW1A 1AA" is useful; "Invalid input" is not, and 3.3.3 asks for the suggestion where you know it.⁴ Do not show errors only with a red border. W3C lists marking required or error fields by colour alone as a failure of 1.4.1; add text or an icon.⁷

Checkout-specific checks

• "Same as delivery address." Offer it, checked by default where that makes sense. That is the everyday way to meet 3.3.7 Redundant Entry.⁴
• A review step or a clear order summary before payment, so an order is checked or confirmed (3.3.4).⁴
• Announce changes. When a discount code is applied, shipping is recalculated, or an item is added to the cart, the message should reach screen reader users without moving focus. W3C's examples for 4.1.3 include a cart count updating after adding an item.⁸
• Allow paste and password managers in login, password and one-time code fields (3.3.8).⁴
• No time limit you cannot extend. W3C's forms tutorial says that if a time limit is needed, people should be able to turn it off or extend it.¹

Shopify: what you control and what you do not

Shopify's checkout is built and maintained by Shopify. Its March 2026 accessibility conformance report covers checkout against WCAG 2.0, 2.1 and 2.2 A and AA, notes that remediation of some issues is ongoing, and states that merchants are responsible for assessing their own online store.¹⁰ What you control in checkout is mainly style: colours for accents, buttons, backgrounds and errors. Shopify's guidance there is to choose high-contrast colours and to keep field text readable, especially with transparent fields.¹¹

Everything before checkout is your theme: newsletter sign-ups, contact forms, product option pickers, gift card fields, the cart and the search box. Shopify's theme guidance asks for a label linked with for on every field, the required and autocomplete attributes, errors linked with aria-describedby, and focus moved to feedback.¹³ Check any app that adds a form, such as reviews, back-in-stock alerts or a wholesale order form, because each brings its own markup.

WooCommerce: watch the theme and checkout plugins

WooCommerce says its checkout labels each field, marks required fields, shows errors visually and in code next to their fields, and announces updates such as cart totals through live regions. It also warns that theme styles can override these defaults, and that themes and plugins that change checkout can break accessibility, so check labels, required indicators and errors after any change.¹² Checkout field editor plugins are the usual suspect: test a checkout after installing one.

Test it in five minutes

1. Click each label. Focus should jump into its field.
2. Fill the form with your browser's autofill. Every personal field should fill correctly.
3. Submit it empty. Read the errors: do they say which field and how to fix it, in text?
4. Do the whole thing by keyboard, then with a screen reader, listening to what each field announces.
5. Run an automated check. axe-core, the engine Jralo uses, has rules for fields without a label and for invalid autocomplete values.¹⁴ Jralo's free check runs them on the pages it opens and also tells you which countries' accessibility laws are likely relevant to your store. It never signs in, adds to a cart or places an order, so the steps above still matter; see why automated testing finds some problems but not all.