Accessible checkout: the fixes that matter most for online stores

Updated October 6, 2026 · 7 min read

Checkout is where an accessibility problem costs a store the most. A shopper who can't finish the form can't buy, and a page that is broken for one person is often broken in the same way for many others.

This guide covers the checkout fixes that tend to matter most, mapped to WCAG 2.1 AA. It is general information and not legal advice. For questions about your legal exposure, talk to an attorney.

Why checkout deserves its own pass

Checkout combines nearly every interactive pattern a web page can have: forms, validation, third-party scripts, timers, modal dialogs and anti-bot tools. Each one is a place where keyboard users, screen reader users, people with low vision and people with cognitive disabilities can be blocked.

A product page can be slightly rough and still usable. A checkout with one unreachable button cannot be completed at all.

If you want the broader picture first, the WCAG 2.1 AA checklist covers the full standard. Product page issues, such as image descriptions, are covered in alt text for product images.

Form labels and instructions

Every field needs a programmatically associated label, not just placeholder text. Placeholders disappear when someone starts typing, usually have weak contrast, and are not reliably announced as labels.

This relates to WCAG 3.3.2 Labels or Instructions, WCAG 1.3.1 Info and Relationships and WCAG 4.1.2 Name, Role, Value.

<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email">

Practical points:

• Use a visible <label> tied to its input with for and id.
• Mark required fields in text (for example "required") and not by color alone.
• Group related fields, such as shipping method options or card expiry parts, in a <fieldset> with a <legend>.
• Put format hints (such as a phone number format) in text that is associated with the field, for example with aria-describedby.

Error messages people can actually use

When a field fails validation, the shopper needs to know that something is wrong, which field it is, and how to fix it. WCAG 2.1 addresses this in Success Criteria 3.3.1 (Error Identification) and 3.3.3 (Error Suggestion). Both are Level A and AA respectively, so they sit within a 2.1 AA audit.

Common failures:

• A red border with no text.
• A generic "Please fix the errors below" banner with no way to find them.
• An error that appears visually but is never announced by a screen reader.
• Focus staying on the submit button after a failed submit.

A workable pattern:

<label for="zip">ZIP code</label>
<input id="zip" name="zip" aria-invalid="true" aria-describedby="zip-error">
<p id="zip-error">Enter a 5-digit ZIP code, for example 90210.</p>

On a failed submit, move focus to a summary of errors at the top of the form, or to the first invalid field. Each item in the summary should link to its field. Write messages in plain language and say what to do, not just what went wrong.

Address autocomplete and autofill

There are two different things here, and they are often confused.

Browser autofill. WCAG 2.1 includes Success Criterion 1.3.5 (Identify Input Purpose), which asks that fields collecting common personal information carry the right autocomplete token. This helps people with motor and cognitive disabilities by reducing typing.

<input id="street" name="street" autocomplete="shipping street-address">
<input id="postal" name="postal" autocomplete="shipping postal-code">

Address suggestion widgets. Third-party type-ahead tools that show a list of suggestions are custom components. They need to work with a keyboard, expose their state to assistive technology, and not trap focus. Test yours by completing an address using only the keyboard. If the suggestion list can't be reached or selected, either fix the widget or make sure a plain manual entry path works without it.

Related: WCAG 2.1.1 Keyboard.

Payment iframes and third-party fields

Many stores use hosted payment fields from a payment provider, embedded in an iframe. You may not control the markup inside, but you are still responsible for what you put on your page.

Check these:

• The iframe has a meaningful title attribute, such as "Card number".
• A visible label sits next to each hosted field.
• Tab order moves naturally into and out of the iframe.
• Focus is visible inside the fields (WCAG 2.4.7 Focus Visible).
• Error messages from the payment step are shown on your page in text, not only inside the frame.

If a provider's hosted fields have a keyboard or screen reader problem you can't fix, report it to them and ask about their accessibility documentation. Some providers publish conformance information. Ask rather than assume.

Timeouts and session expiry

Checkout sessions that expire can lock out people who need more time, including people using screen readers, switch devices or voice control. WCAG 2.1 covers this in Success Criterion 2.2.1 (Timing Adjustable).

If you have a timeout, the usual approach is to:

• Warn the user before it happens, with enough time to respond.
• Let them extend it with a simple action.
• Preserve their entered data if the session does end.

There are exceptions in the standard, for example when a time limit is essential. If you use a cart reservation timer for scarce inventory, check whether it is truly essential or whether you can offer an extension.

CAPTCHA and bot protection

Image puzzles and distorted text are a known barrier. WCAG 2.1 Success Criterion 1.1.1 (Non-text Content) says CAPTCHAs need text alternatives that identify their purpose, and that alternative forms should be provided for different senses.

Options, in rough order of preference:

1. Skip CAPTCHA for logged-in users or known sessions.
2. Use bot detection that doesn't ask the shopper to do anything, such as server-side risk scoring or rate limiting.
3. If you must use a challenge, offer more than one type (for example visual and audio) and test that both work with a keyboard and screen reader.

A single image puzzle with no alternative is a common checkout blocker, so it's worth confirming what your current tool does rather than assuming.

Order confirmation and status messages

After payment, the shopper needs to know it worked. Many stores update the page with JavaScript and show a message that screen reader users never hear.

Success Criterion 4.1.3 (Status Messages) is part of WCAG 2.1 AA. A status message that appears without moving focus should be announced, typically with a live region:

<div role="status">Order placed. Confirmation sent to your email.</div>

Also check that:

• The confirmation page has a clear title (WCAG 2.4.2 Page Titled).
• The order number and next steps are real text, not an image.
• Links like "Track order" make sense on their own (WCAG 2.4.4 Link Purpose).

A quick priority table

How to test your checkout

Run through a full purchase three ways:

1. Keyboard only. Use Tab, Shift+Tab, Enter and Space. You should be able to reach and operate everything, and always see where focus is.
2. Screen reader. Try a free one such as NVDA, or VoiceOver on a Mac or phone. See screen reader testing basics.
3. Zoom to 200%. Content should stay readable and usable (WCAG 1.4.4 Resize Text). Check text contrast too (WCAG 1.4.3).

Automated tools catch only part of the picture. They are good at missing labels and contrast, and weak at judging whether an error message makes sense. Manual testing fills the gap. A dated accessibility audit record can help you show what you checked and when.

If you've received a demand letter, see what to do about an ADA website demand letter and speak with an attorney. Fixing issues does not by itself guarantee any legal outcome. To see where your store stands today, run a free scan.

Frequently asked questions

Which checkout problem should I fix first?

Start with anything that stops a purchase entirely: buttons or fields a keyboard can't reach, unlabeled payment fields and image-only CAPTCHAs. After that, work on error messages and labels. Blockers come before polish.

Do I have to fix my payment provider's hosted fields?

You are responsible for your page, including the iframe's title and surrounding labels. You may not control the markup inside the frame. If a hosted field has a barrier, report it to the provider and ask about their accessibility information.

Is CAPTCHA allowed under WCAG 2.1 AA?

WCAG doesn't ban CAPTCHA. It asks that a CAPTCHA be identified with a text alternative and that other forms of the challenge be available for different senses. Invisible or server-side bot detection avoids the issue for most shoppers.

Will fixing these items make my store compliant?

No. Passing these checks reduces barriers, but WCAG conformance covers the whole site, and no single fix list guarantees legal protection. This is not legal advice, so ask an attorney about your specific situation.

How often should I retest checkout?

Retest after any change to the theme, plugins, payment provider or shipping tools, since each can alter the form or add scripts. A regular scheduled check also catches regressions that nobody notices in day-to-day work.

Related

• WCAG 2.1 AA checklist for business websites
• Screen Reader Testing for Business Owners: VoiceOver and NVDA Basics
• WCAG 3.3.2 Labels or Instructions
• WCAG 2.1.1 Keyboard

Proof of Access provides technical accessibility assessments. We are not a law firm and nothing on this page is legal advice. If you have received a demand letter or a lawsuit, talk to an attorney.