How to Build Accessible Forms

An accessible form is one any person can complete using a keyboard, a screen reader, or other assistive technology. That means every input has a real, programmatically connected label, required fields and errors are announced (not just colored red), and related controls are grouped. Done right, forms meet WCAG 2.1 AA and stop being a lawsuit risk.

Forms are where accessibility problems do the most damage. A missing label on a blog image is a nuisance; a missing label on a checkout field can stop a blind customer from buying anything. Because contact and checkout forms create concrete, provable harm, they show up constantly in ADA web complaints. The good news: nearly every form barrier is fixable in the markup.

Start with real labels

The single most important rule of form accessibility is that every input needs a visible label tied to it in code. A label is connected to its field by matching the for attribute on the <label> to the id on the <input>:

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

When the association is correct, a screen reader announces “Email address, edit text” when the user reaches the field. Clicking the label also focuses the input—a usability win for everyone, including people with motor impairments.

What does not count as a label:

• Placeholder text. It vanishes the moment someone types, is inconsistently read by NVDA, JAWS, and VoiceOver, and almost always fails color contrast requirements.
• Visual-only proximity. Text sitting next to a field looks like a label to sighted users but is invisible to assistive technology unless it’s coded as one.
• A red asterisk alone. It signals “required” visually but says nothing to a screen reader.

This maps directly to WCAG success criteria 1.3.1 (Info and Relationships), 3.3.2 (Labels or Instructions), and 4.1.2 (Name, Role, Value). The W3C/WAI tutorials on forms are the canonical reference if you want the underlying spec.

Group related fields with fieldset and legend

When several controls answer one question—a set of radio buttons, a group of checkboxes, or a multi-part field like a billing address—wrap them in a <fieldset> with a <legend>. The legend gives the whole group a name that assistive technology announces alongside each option.

<fieldset>
  <legend>Shipping speed</legend>
  <label><input type="radio" name="ship" value="standard"> Standard</label>
  <label><input type="radio" name="ship" value="express"> Express</label>
</fieldset>

Without the fieldset, a screen-reader user hears “Standard, radio button” with no context for what they’re choosing. With it, they hear “Shipping speed, Standard, radio button.” This is exactly the kind of relationship that automated scanners miss and that manual accessibility testing is built to catch.

Required fields and error handling

Most form lawsuits and audit failures cluster around two things: how you mark a field as required, and what happens when someone gets it wrong.

Mark required fields in code, not just color. Use the native required attribute (and aria-required="true" for older assistive tech) so the requirement is announced, not just shown as a red star.

Handle errors so they’re perceivable and actionable. Per WCAG 3.3.1 (Error Identification) and 3.3.3 (Error Suggestion), an accessible error message must:

• Identify the field in text, not color alone (color fails for low-vision and colorblind users).
• Say what went wrong and how to fix it—“Enter a valid email like name@example.com,” not just “Invalid.”
• Be programmatically linked to its input with aria-describedby, and mark the field with aria-invalid="true".

<label for="phone">Phone number</label>
<input type="tel" id="phone" name="phone"
       autocomplete="tel" aria-describedby="phone-err" aria-invalid="true">
<span id="phone-err">Enter a 10-digit phone number, e.g. 555-123-4567.</span>

On submit failure, move focus to the first error or to a summary at the top of the form so screen-reader users immediately know the submission failed and why. Silent failures—where the form simply doesn’t submit and nothing is announced—are one of the most frustrating barriers there is.

Autocomplete and input types

Two small choices make forms dramatically easier for people with cognitive and motor disabilities, and they’re required by WCAG 2.1 AA success criterion 1.3.5 (Identify Input Purpose):

• Use autocomplete tokens on common fields: autocomplete="name", "email", "tel", "street-address", "postal-code". This lets browsers and assistive tools fill fields accurately so users don’t retype the same information.
• Use the right type. type="email", type="tel", and type="number" trigger the correct on-screen keyboard on mobile and add built-in validation.

ARIA: use it sparingly

The first rule of ARIA is don’t use ARIA when native HTML already does the job. A real <button>, <label>, and <fieldset> give you accessible names, roles, and keyboard behavior for free. Reach for ARIA only to fill genuine gaps:

Misused ARIA actively breaks forms—an aria-label that contradicts the visible label, or a custom <div> styled as a button that keyboards can’t reach. That’s why keyboard navigation testing matters: if you can’t Tab to a field, type in it, and submit with Enter, no amount of ARIA will save it.

Common form failures that get sites sued

Thousands of ADA web lawsuits and demand letters are filed each year, and forms are repeat offenders. The patterns below appear again and again in complaints under ADA Title III:

1. Unlabeled inputs on contact and checkout forms. The number-one failure. A screen reader reaches a blank field and reads the file name or nothing at all.
2. Errors shown by color only. A red border with no text message leaves colorblind and blind users stuck.
3. Keyboard traps. A date picker or modal you can Tab into but not out of.
4. Inaccessible CAPTCHAs. A visual-only CAPTCHA with no audio or alternative blocks the entire form.
5. Placeholder-as-label. Looks clean, fails completely once text is entered.

Checkout forms draw the most legal attention because a blocked purchase is concrete, demonstrable harm—exactly what plaintiffs’ attorneys look for. If you run a store, our guide to ADA compliance for ecommerce covers the checkout-specific risks in detail. (This is general information, not legal advice; if you’ve received a demand letter, talk to an attorney.)

Why overlays can’t fix forms

Accessibility overlays—the third-party widgets sold by vendors like accessiBe, UserWay, and AudioEye—promise instant compliance with a line of JavaScript. They can’t deliver it for forms. An overlay has no way to know which visible text belongs to which input, what a specific error actually means, or how your multi-step checkout is supposed to flow. It’s guessing, and screen-reader users feel the difference immediately. That’s why overlays don’t ensure ADA compliance, and why they keep showing up in lawsuits rather than preventing them.

Real form accessibility lives in the HTML: the right labels, the right groupings, the right error wiring. That’s manual work, and it’s exactly what we do.

Fix your forms the right way

Labels, fieldsets, errors, and inputs are very fixable—but only by editing the code that produces them. If you’d rather not hand-audit every field, Curbcut’s accessibility remediation service repairs your forms to WCAG 2.1 AA by hand, no overlay involved. Not sure where you stand? Start with a free accessibility scan and we’ll show you which forms need attention first.