A customer has chosen a product, added it to the cart and pressed “Proceed to checkout”. They have already decided to pay you. Everything from this point on is either helping them finish or getting in their way, and checkout accessibility decides which.
An accessible checkout is one that a person can complete using only a keyboard, a screen reader, voice input, a magnified screen or a phone held in one hand, without guessing. This post goes through a typical checkout in order, field by field, with what to check and what to change. It applies to WooCommerce, Shopify and custom builds alike, although what you are able to change differs by platform.
Before the first field: guest checkout and sign-in
Forcing people to create an account before they can pay adds a password field, a confirmation field and often an email verification step. Each of those is another place to fail. Offering guest checkout is good practice for everyone, and it removes a whole set of barriers for people who find forms tiring.
If returning customers can sign in at checkout, look at that sign-in box carefully. WCAG 2.2 criterion 3.3.8 Accessible Authentication (Minimum) says logging in should not rely on a memory or transcription test unless there is a way around it. In practice:
- Let password managers fill the password; do not block paste.
- If you send a one-time code, let people paste it, and do not split it into six separate boxes that break autofill.
- Offer “email me a sign-in link” if your platform supports it.
Contact and address fields
These are the bulk of any checkout, and the fixes are mostly simple.
Every field needs a visible label
Placeholder text that vanishes when you start typing is not a label. Someone who gets interrupted halfway through the address cannot tell which box is “Address line 2” and which is “Town / City”. The label should sit above or beside the field and stay there. Criterion 3.3.2 Labels or Instructions covers this.
Use the browser’s autofill
Autofill saves typing for everyone, and for someone using a switch device or voice control it saves a great deal of effort. It works when each field carries the right autocomplete value. Most platforms add these for their own fields, but custom fields added by plugins often lack them.
<label for="billing-email">Email address</label>
<input id="billing-email" type="email" autocomplete="email" required>
<label for="billing-zip">ZIP code</label>
<input id="billing-zip" type="text" autocomplete="postal-code" inputmode="numeric">Using type="email" and inputmode="numeric" also brings up the right keyboard on a phone.
Mark required fields in words, not only with color
An asterisk is fine if you explain it once at the top (“Fields marked * are required”) and the field itself is marked as required in the code so a screen reader says so. Better still, ask only for what you need and mark the few optional ones as “(optional)”.
Country and state selectors
Many checkouts replace the plain country dropdown with a searchable select box. Some of these work well with a keyboard and screen reader; some trap focus or announce nothing as you type. Test it: Tab to it, type the first letters of a state, press Enter, and listen to what is announced.
Shipping address the same as billing
WCAG 2.2 added 3.3.7 Redundant Entry: information a person already gave in the same process should be filled in again for them or available to select. For a checkout, that means a “Ship to the same address” option that is checked by default, and not making people retype an email address they entered on the previous step.
When that box is unchecked and a second address form appears, focus should not jump around, and a screen reader user should be able to find the new fields directly after the checkbox.
Shipping methods, coupons and totals
Shipping options are usually radio buttons. They need a group name (“Shipping method”) and each option should read with its price, such as “Standard, 3 to 5 business days, free”. When a choice changes the order total, the new total should be announced, or at least be easy to reach right after the options.
Coupon fields are often hidden behind a “Have a coupon?” link. That link should be a button that says whether the field is expanded, and the result of applying a code, accepted or rejected, should be announced right where the person is working.
The payment step
This is the part store owners control least. Card fields are commonly loaded inside an iframe served by the payment provider, so the provider is responsible for the labels and errors inside it. You still have choices:
- Test the provider’s fields with a keyboard and a screen reader using test mode. Can you reach card number, expiry and security code in order? Are errors such as “card number is incomplete” announced?
- Check the frame’s title. A screen reader announces an iframe by its title. “Secure card payment input frame” is helpful; a blank title or a random string is not.
- Check wallet and express buttons. Apple Pay, Google Pay and similar buttons should have names that say what they do. Several stacked express buttons can also push the regular form far down the page.
- Watch for popups and redirects. Bank verification screens may open in a new layer. Focus should move into it and come back afterwards.
If a provider’s fields cannot be used without a mouse, raise it with them and consider whether another provider your platform supports does better. An accessible checkout depends on those fields as much as on your own, so test a provider before you switch, not after.
Errors at checkout
Many checkout problems turn out to be error handling. Someone submits, nothing seems to happen, and somewhere above the fold a red box lists three problems. A screen reader user hears nothing; a person zoomed to 200 percent sees nothing.
The minimum is that each error says what is wrong in text, is connected to its field, and is announced or receives focus. A list of errors at the top with links to each field also helps on long forms. The detail of how to write and wire up errors is in our post on accessible error messages; checkout errors that come from server problems rather than missing fields are covered in our WooCommerce checkout error fix service.
Timeouts, reviews and the final button
Some checkouts expire a session or hold stock for a limited time. If yours does, warn people before time runs out and let them extend it with a simple action. People using screen readers, switch devices or voice input often take longer, and losing a filled-in form is a common reason they give up.
Before the final button, the order summary should be readable as text: product names, options chosen, quantity, price, shipping and total. If it is a table, it needs header cells. Terms and conditions checkboxes need a label that includes the words, not just a link floating next to an unlabeled box.
The “Place order” button itself should be a real button with a clear name, large enough to press, and not covered by a chat bubble or cookie notice on a phone. WCAG 2.2 criterion 2.4.11 Focus Not Obscured (Minimum) applies here: when the button has keyboard focus, sticky footers and floating widgets should not hide it.
Spam and bot checks at checkout
Stores that suffer card-testing attacks sometimes add a CAPTCHA to checkout. A puzzle in the last step is a hard barrier for many people. Look at less intrusive options first; our post on CAPTCHA alternatives that people can actually pass compares them.
The confirmation page
After payment, the confirmation page should have a clear heading such as “Thank you, your order is confirmed” so a screen reader user knows it worked, plus the order number in text. The confirmation email should carry the same information in real text, not an image.
An accessible checkout test you can run in fifteen minutes
- Put your payment provider in test mode, or use a staging copy of the store.
- Add a product with options to the cart and go to checkout using only the keyboard.
- Submit the empty form once on purpose. Note where focus goes and what you can tell from the screen.
- Fill the form using autofill and see which fields stay empty.
- Uncheck “same shipping address”, then check it again.
- Apply a wrong coupon, then a right one.
- Complete payment with a test card and read the confirmation page.
- Repeat with a screen reader, then on a phone.
This test covers one stage of the store-wide shopping journey, and field-level fixes for other forms are on the accessible form fixes page.
Frequently asked questions
Why do checkout errors trip up so many shoppers?
Because they are often not announced. A customer submits the form, a message appears somewhere else on the page, and focus stays on the button. Sighted mouse users usually spot it; screen reader and keyboard users often do not. Connecting each error to its field and moving focus to the first one fixes much of this.
Can I fix the card fields from my payment provider?
Usually not directly, because they load inside a frame from the provider. You can test them in test mode, give the frame a clear title if your platform allows it, report problems to the provider and choose a provider whose fields work with a keyboard and screen reader. Test before switching providers.
Is guest checkout required for accessibility?
WCAG does not require guest checkout. It does reduce the number of fields, passwords and verification steps a person has to get through, so it removes several common barriers at once. If you require accounts, make sure the sign-in and registration steps allow password managers and pasted codes.
Does checkout need to work on phones as well as desktop?
Yes. Many people with disabilities shop on phones, often with VoiceOver or TalkBack, zoom or large text settings. Check that fields stay readable at large text sizes, that buttons are big enough to tap and that floating chat or cookie elements do not cover the Place order button.
When we work on a store, checkout is where we start: we test it with a keyboard and screen readers, fix what the theme and plugins control, and note anything that sits with the payment provider. That work is described on our accessible WooCommerce store page, part of our website accessibility hub.
Next in this series: Accessible Form Design: Labels, Groups and Layout
