Close your eyes for the next few minutes. Unplug your mouse. Now try to buy a pair of shoes using only a keyboard and a voice reading the screen to you — that voice being NVDA or VoiceOver, narrating whatever your code actually says. This is how millions of people shop every day. It’s also where most online stores quietly stop working.

A checkout is the single most form-dense page on an ecommerce site, and forms are the part of the web that fails assistive technology most often. In the 2026 WebAIM Million, 33.1% of all form inputs weren’t properly labeled, and 51% of home pages had at least one missing form label — and that’s just home pages, before anyone reaches the checkout. Let’s walk the flow the way a screen reader user does and fix each break as we hit it.

Step 1: The fields that whisper nothing

The screen reader user tabs into the address form. The voice says: “Edit, blank. Edit, blank. Edit, blank.” Three text fields in a row with no idea what any of them want.

Sighted shoppers see a faint gray placeholder — “First name,” “Last name,” “ZIP.” But placeholder text is not a label. It often isn’t exposed to assistive technology, it vanishes the instant you start typing, and it fails contrast checks. The field needs a real, programmatically associated <label> (or aria-label when there’s genuinely no visible text). Without it, the screen reader has nothing to announce.

The fix is unglamorous and bulletproof: every input gets a <label for> tied to the input’s id, or wraps the input directly. Card number, expiry, CVC, ZIP — all of them. This is also the most common failure on the entire web, so fixing it is high-leverage: it’s been one of WebAIM’s six most common errors for seven years running.

Step 2: Focus that teleports away

The user selects a country. A shipping-options panel loads via JavaScript — and focus silently jumps to the top of the document, or worse, nowhere. The voice goes quiet. The user has no idea anything changed, so they keep tabbing into an empty void.

Dynamic checkouts break the one thing screen reader users rely on: a predictable keyboard focus order. When content appears, removes itself, or reorders, focus has to be managed deliberately — send it to the new content, or leave it exactly where the user left it. Modal coupon dialogs are the classic offender: open one, and if focus isn’t moved into it and trapped, the user is reading the page behind the dialog while sighted users see an overlay. Most screen reader users navigate long pages by headings — 71.6% of them, per WebAIM’s Screen Reader Survey #10 — so a checkout with no heading structure and runaway focus is genuinely disorienting.

Step 3: The error you can’t hear

The user fills everything in, presses Enter, and the page does… something. Visually, the card field turns red and a message appears: “Invalid card number.” The screen reader says nothing at all. The user sits there assuming the order went through, or tabs around hunting for a problem they can’t perceive.

This is the cruelest break in checkout, and it’s a direct WCAG failure on two counts. Success Criterion 3.3.1 Error Identification requires that errors be described in text — not just a red border or an icon. Success Criterion 4.1.3 Status Messages requires that messages appearing without a focus change still get announced.

The fix is a specific recipe, not a vibe:

  • Put the error text in a live region — role="alert" for urgent validation, or aria-live="polite" for a running summary — so it’s spoken the moment it renders.
  • Set aria-invalid="true" on the offending field and link the message with aria-describedby so the user hears the error and the field it belongs to when they land on it.
  • Move keyboard focus to the first error (or to a summary at the top that links to each bad field). Don’t make someone hunt.
  • Never rely on color alone — red text plus a clear sentence, every time.

Step 4: The button that isn’t a button

Final hurdle: “Place order.” On too many sites it’s a styled <div> with a click handler, or an icon-only button with no text. The voice announces “clickable” — or nothing — and there’s no way to know this is the button that spends your money. A blind plaintiff named Guillermo Robles ran into exactly this class of barrier on Domino’s ordering flow; the Ninth Circuit ruled the ADA applied and the Supreme Court let that ruling stand in 2019. Checkout buttons that only work for a mouse aren’t an edge case — they’re litigated.

Use a real <button> element with a clear accessible name (“Place order — $128.40”), make sure it’s reachable and operable by keyboard, and confirm the success state in a live region too, so the user actually hears “Order confirmed.”

Why this matters beyond empathy

Ecommerce is the most-sued category in digital accessibility by a wide margin — 77% of the 4,000-plus digital ADA lawsuits filed in 2024 targeted online stores, according to UsableNet’s 2024 year-end report. The checkout, where the money is, is where demand letters tend to point. And the shortcut everyone hopes will save them doesn’t: in 2024, over 1,000 businesses were sued despite having an overlay widget installed — more than a quarter of all cases. A widget can’t guess what your unlabeled CVC field means or repair a broken focus flow. (None of this is legal advice; if you’ve received a complaint, talk to an attorney.)

The good news: every break above is a known, fixable pattern in your own HTML and ARIA. That’s the work Curbcut does by hand — real remediation on the actual code, not a script bolted over the top. If you want to know which of these four breaks your checkout has right now, start with a free scan, then dig into the ecommerce accessibility playbook to harden the rest of the funnel.