Checkout Accessibility Testing
Run one journey test across the whole purchase — cart to confirmation, keyboard only, the way a screen-reader customer makes it — and find the step where the order stops.
- Passed. Tab 1
- “banner landmark, Accessible, link”
- Passed. Tab 2
- “main landmark, heading level 1, Checkout”
- Passed. Tab 3
- “Shipping address, edit, required”
- Critical. Tab 4
- “edit, blank”
Tabs 4 through 7 all announce “edit, blank”. Nothing distinguishes the card number from the expiry, the security code, or the postcode.
Example output, produced by Accessible on a test site. Not a customer site, and no customer data is shown.
What does an accessible checkout need?
Every step of the purchase has to work from the keyboard and make sense when read aloud: each field named, each error announced and tied to its field, focus moved into every dialog and back out, and a chance to review before paying. A checkout is accessible when a screen-reader customer can finish the order — not when each page passes a scan.
Proving that takes a journey test: one attempt at the whole task, step by step, rather than a rule check of each page on its own.
Why checkout carries the most risk
Checkout is where an accessibility failure costs an order outright, and it is where legal attention concentrates. eCommerce accounted for 70% of the ADA digital accessibility lawsuits UsableNet tracked in 2025, and 36% of the top 500 eCommerce retailers received at least one (UsableNet, 2025).
It is also the hardest flow to test by looking at pages. A checkout is a sequence of states — drawers, dialogs, validation, provider-hosted payment fields, confirmation — and most of what goes wrong happens between page loads.
- Who it stops
- A blind user reaches the field and hears no label, so there is nothing to tell it from the three inputs beside it. The purchase ends here.
- Fix
- <input id="cc" type="text" />+ <label for="cc">Card number</label>+ <input id="cc" type="text" />
Example output, produced by Accessible on a test site. Not a customer site, and no customer data is shown.
The checkout barriers that stop an order
These come up in checkout after checkout. Most are invisible until someone tries to buy something. The first one is the run at the top of this page — four payment fields that each announce “edit, blank” — and the card beside it is how Accessible files that barrier: criterion, who it stops, and the markup change that fixes it.
Payment fields that cannot be told apart
Card number, expiry, security code and postcode each announce "edit, blank". Payment fields are often embedded from a provider in a frame, so their labels and error messages are set in that provider’s configuration rather than in your own markup — and are easy to miss in review.
WCAG 1.3.1 · 3.3.2 · 4.1.2
Address forms that fight autofill
Fields without the right autocomplete purpose make people retype a full address on a small screen or with a switch device. Asking again for an address already entered earlier in the same checkout adds to it.
WCAG 1.3.5 · 3.3.7
Errors that appear but are never announced
A declined card or a missing postcode turns a field red. If the message is not tied to the field and announced, a screen-reader user presses Pay again and hears nothing change.
WCAG 3.3.1 · 3.3.3 · 4.1.3
Guest checkout and sign-in dialogs
A "continue as guest" modal opens without moving focus into it, or traps focus so the only way out is to reload. Either one ends the order before payment.
WCAG 2.1.2 · 2.4.3
Cart updates nobody hears
Changing a quantity or applying a discount updates the total silently. The customer cannot confirm what they are about to pay for without re-reading the whole page.
WCAG 4.1.3
The last step before payment
Purchases are exactly where WCAG asks for a chance to review, correct or confirm before submitting — and where a session timeout with no warning or extension undoes the whole flow.
WCAG 2.2.1 · 3.3.4
Payment fields inside a provider's iframe: scanning covers them — axe-core runs in every frame on the page, so a missing label on a hosted card field is reported like any other. A journey drives the page itself, so it reports the checkout up to and around those fields but does not inspect what is inside the provider's frame. For the fields themselves, use your provider's own accessibility documentation, or check them by hand with a screen reader.
How Accessible tests a checkout
Three engines, each covering what the others cannot reach on a purchase flow.
Journey testing: attempt the purchase
Name the task — buy one product as a guest, or sign in and reorder. A simulated screen-reader user works through it keyboard-only in a real browser, and after every click or keystroke checks what was announced, where focus landed, whether a status message was spoken, and whether the form still makes sense. The report names the step the order stopped at, classifies the barrier against a WCAG 2.2 criterion with the fix, and marks every later step not reached rather than passed. Run it against staging or a store in test mode with test payment details, on a schedule, or on every deploy on Professional and Enterprise.
How journey testing worksReal user monitoring on real orders
A journey covers the path you scripted. Real customers bring saved addresses, discount codes, declined cards and third-party widgets. Real user monitoring runs checks in their sessions, catches focus traps and focus that is not visible as they happen, and ranks each barrier by how many sessions met it — without ever sending what a customer typed.
How monitoring worksAutomated scanning: every page around it
Automated scanning covers the product, category and cart pages that lead into checkout, catching missing labels and contrast failures on each one, on a schedule, and on deploy on Professional and Enterprise — unmetered, with no cap on URLs.
How scanning works
Testing a checkout yourself? Start with how to test a website with a screen reader, focus management for dialogs and the WCAG 2.2 checklist.
Sources
- 2025 Year-End Digital Accessibility Lawsuit Report (opens in a new tab). UsableNet, December 2025. Litigation tracking by an accessibility vendor; federal courts plus New York and California state courts.
Frequently asked questions
What is checkout accessibility testing?
Testing whether a person using a keyboard or screen reader can complete a purchase from start to finish — cart, sign-in or guest checkout, address, delivery, payment and confirmation — rather than checking each page of the checkout on its own.
Why test the whole checkout instead of scanning each page?
Most checkout failures only appear while someone is using it: a dialog that does not take focus, a payment error that is never announced, a total that updates silently. Each page can pass an automated scan while the order still cannot be placed.
How often should we test checkout accessibility?
Re-run the checkout journey on every deploy that touches the flow, and on a weekly or monthly schedule otherwise, because a checkout changes whenever payment, promotions or a third-party widget change. Monitoring runs continuously alongside it, so a barrier introduced between releases still surfaces.
Can a journey run a checkout without placing a real order?
Run checkout journeys against a staging site or a store in test mode, and give the journey test account and test payment details. Journeys type whatever values you provide into the fields; never use a live card.
Can you test payment fields hosted in a provider’s iframe?
Scanning can: axe-core runs in every frame on the page, so a card field with no accessible name is reported wherever it lives. A journey drives the page itself, so it tests the checkout around those fields — labels, errors, focus, the steps before and after — but does not inspect the inside of the provider’s frame. Check the fields themselves against your provider’s accessibility documentation, or by hand with a screen reader.
Does monitoring collect what customers type into checkout forms?
No. The monitoring script never sends page text or form values. It records the route path, the rule or behavior that failed, the element’s structure and allowlisted attributes, and viewport and zoom context.
Which WCAG criteria matter most for checkout?
Labels and names for every field (1.3.1, 3.3.2, 4.1.2), input purpose for autofill (1.3.5), error identification and suggestions (3.3.1, 3.3.3), error prevention for financial transactions (3.3.4), status messages (4.1.3), keyboard access without traps (2.1.1, 2.1.2) and focus order (2.4.3).
Find the step your checkout breaks on.
Run a journey through your purchase flow, monitor real orders, and scan every page that leads there.