Screen reader users can't complete your forms because the fields don't speak. A screen reader reads what the code exposes — label text, field type, required state, and error messages — so when a field has no programmatic label, its errors appear only in red, or its "button" is really a styled div, the user hears an unlabeled edit box and a form that fails silently. The result is an abandoned cart and, increasingly, a demand letter. Building accessible forms is mostly about making structure and state visible to assistive technology, and the seven mistakes below cause most checkout failures we find in audits.
Forms are where accessibility problems turn into lost revenue, because a form is the one place a visitor must succeed to buy. Missing form labels rank among the most common failures on the web — WebAIM's 2025 analysis found detectable WCAG failures on 94.8% of the top million homepages, with form labels a leading culprit. E-commerce accounts for roughly 70% of web-accessibility lawsuits, and checkout is the flow plaintiffs test first.
Why do missing labels break the whole form?
A visible label sitting next to a box means nothing to a screen reader unless it is programmatically associated with the input. Without that link, the user hears "edit, blank" and has to guess what to type.
Associate every input with a real label element, connecting the label's for attribute to the input's id. Where a visible label isn't possible, use an aria-label or aria-labelledby — never leave a control nameless.
Placeholders are not labels
Placeholder text disappears the moment someone types, usually fails color-contrast minimums at its typical gray, and is skipped by some screen readers. Use a persistent visible label and treat the placeholder as an optional example, not the field's name.
Why don't screen reader users hear my error messages?
Turning a field border red and adding red helper text communicates nothing to a non-visual user — color alone is never an accessible signal. The error has to be real text, tied to the field, and announced when it appears.
Link the message to the input with aria-describedby, mark the field aria-invalid, and render validation errors inside a live region so the message is spoken the instant it renders. On submit, move focus to the first error and give a specific instruction ("Enter a valid ZIP code"), not a generic "Invalid input."
How should required fields and grouped inputs be marked?
An asterisk or a red outline tells sighted users a field is required. Screen reader users need it in the accessibility tree.
Add the native required attribute (or aria-required) to the input, and state the convention in text near the top of the form. Don't rely on the asterisk character alone.
Group related controls
Radio buttons and checkbox sets — shipping options, card type, saved addresses — belong inside a fieldset with a legend. Without the legend, a screen reader announces "Standard, radio button" with no context for what that choice controls. The legend supplies the question; each label supplies one answer.
Why do custom "buttons" and dropdowns trap screen reader users?
Design systems love styling a plain div or span to look like a button, checkbox, or select. To a screen reader, a bare div is nothing — no role, no state, no keyboard behavior. The "Place Order" control that looks perfect can be completely unreachable.
Use native HTML elements first: button, input, select. They ship with roles, focusability, and keyboard support for free. If a custom widget is truly unavoidable, add the correct role, manage its tab order, wire up keyboard handlers, and expose state such as checked or expanded. Then confirm it by hand — the keyboard-only navigation test covers what to check.
How does focus behavior make or break checkout?
Focus is how a keyboard or screen reader user knows where they are. Break it and the form becomes a maze.
Keep a visible focus indicator
Never strip the focus outline without a replacement. WCAG 2.2 added Focus Appearance (2.4.11) precisely because invisible focus is so common — the rundown of what changed in WCAG 2.2 covers the new criteria. Every interactive element needs a clear focus style that meets contrast minimums.
Manage focus order and don't strand it
Focus order must follow reading order, and dynamic content — an inserted coupon field, an expanded address panel, a modal — must receive focus deliberately. After validation, send focus to the first problem field. After a successful step, send it to the new step's heading. Focus that vanishes to the top of the page, or gets stuck behind an overlay, ends the session.
Why do CAPTCHAs and timeouts stop people at the finish line?
A visual-only CAPTCHA is a wall for anyone who can't see the image, and cognitive puzzles are barriers under WCAG 2.2's Accessible Authentication criteria (3.3.8/3.3.9). Session timeouts that clear a cart with no warning punish anyone who needs more time.
Offer an authentication path that doesn't force a memory or transcription test — support password managers and copy-paste, and avoid puzzle-based checks. Give timeouts a warning and an easy way to extend, and preserve entered data so a slow-but-successful user isn't dumped back to an empty form.
Why won't an overlay widget fix these form problems?
It's tempting to bolt on a third-party script that promises instant compliance. It won't build accessible forms for you. A surface-layer compliance overlay can't reliably create the label associations, error semantics, and focus management your checkout needs — WebAIM found sites running overlays averaged about as many detectable errors as sites without them, and in January 2025 the FTC ordered accessiBe to pay $1 million over deceptive claims that its widget could make any site compliant. That is different from an honest preference widget — a contrast or text-size toggle on a site that's already accessible in code, making no compliance claim (ADA Fail runs one). Attack the false compliance claim, not the preference button; the difference between an accessibility widget and a compliance overlay is worth understanding before you buy either.
The durable fix is in the markup. Clean semantics let your form pass automated scans for the machine-detectable issues — though automated tools catch only about a third of WCAG success criteria, so real confidence comes from expert human testing against WCAG 2.2 AA. Work through the accessibility compliance checklist and validate the whole flow with a screen reader, following the walkthrough on how to test a website with a screen reader.
Checkout is the most expensive place to get accessibility wrong, and forms are where it breaks most. Request a free accessibility audit and we'll test your actual checkout flow against WCAG 2.2 AA — automated scan plus human review — and hand you the code-level fixes to get every customer through.
Frequently asked questions
Do I need to use ARIA to make my forms accessible?
Usually less than you'd think. Native HTML elements — label, input, button, fieldset, select — already expose the right roles, states, and keyboard behavior, so reach for them first. ARIA is for the gaps: associating error text with a field, announcing dynamic messages in a live region, or describing a custom control that has no native equivalent. Incorrect ARIA is worse than none, so add it deliberately and test the result.
Can an automated scanner catch all my form accessibility problems?
No. Automated tools reliably flag machine-detectable issues — a missing label, an empty button, low contrast — but they can only evaluate roughly a third of WCAG success criteria. A scanner can't confirm that your error message is announced at the right moment, that focus lands on the first invalid field, or that the checkout makes sense read aloud from start to finish. Those need a human testing with an actual screen reader, which is why full-conformance judgments only come from expert review.
Which form field is most likely to get a checkout sued?
There's no single field, but the highest-risk failures are the ones that block completion outright: unlabeled inputs, errors that are never announced, and a submit control built from a non-interactive element. E-commerce makes up about 70% of web-accessibility lawsuits, and testers go straight for the buy flow. Fixing labels, error semantics, and native controls closes the failures that most often turn a broken checkout into a legal claim.