Making Forms Accessible: A Practical WCAG Guide

Why Form Accessibility Is So Often Broken

Forms are where accessibility failures have the greatest real-world consequences. An inaccessible checkout form means a user cannot purchase a product. An inaccessible contact form means a user cannot get support. An inaccessible registration form means a user cannot access a service. These are concrete barriers — not theoretical ones.

Despite this, form accessibility is routinely neglected. The most common reason: form elements have default browser styling that developers override aggressively for visual consistency, and in doing so, they break the semantic relationships that make forms accessible.

The Foundation: Labels

Every form input needs an accessible name. This is the text that a screen reader announces when the user focuses the input. Without it, a screen reader announces only the input type — "text field" or "checkbox" — with no indication of what it is for.

Method 1: Explicit Label (Preferred)

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

The for attribute value must match the id of the input exactly. The label is also clickable, expanding the click target for the input — a usability benefit for motor-impaired users.

Method 2: aria-label (When No Visible Label)

<input type="search" aria-label="Search the site" />

Use this only when a visible label is genuinely not feasible. Whenever possible, provide a visible label — invisible labels create issues for users with cognitive disabilities.

What NOT to Use as a Label

• Placeholder text: Not read consistently by all screen readers, disappears on input, and typically fails contrast requirements.
• Title attribute: Not consistently exposed by screen readers and not reliable for accessibility.
• Visual proximity: A label that is visually near an input but not programmatically associated is invisible to assistive technology.

Grouping Related Controls

When inputs are logically related — like a group of radio buttons for payment method — they must be wrapped in a <fieldset> with a <legend>.

<fieldset>
  <legend>Preferred contact method</legend>
  <label><input type="radio" name="contact" value="email"> Email</label>
  <label><input type="radio" name="contact" value="phone"> Phone</label>
</fieldset>

Without the fieldset/legend, a screen reader user hears "Email, radio button, 1 of 2" with no context for what the choice is about.

Required Fields

Marking a field as required must be done both visually and programmatically. The HTML required attribute handles the programmatic announcement. For the visual marker, use text ("Required") or an asterisk with an explanatory note — never color alone.

Error Messages

When form validation fails, errors must be announced to screen reader users — not just displayed visually. Use aria-describedby to link the error message to its input, aria-invalid="true" to signal the error state, and role="alert" on the error message so it is announced automatically when it appears.

Autocomplete for Common Fields

WCAG 1.3.5 requires that inputs collecting personal information use the HTML autocomplete attribute with a valid value. This enables browser autofill and third-party tools used by users with motor disabilities who find typing difficult.

<input type="text" id="name" autocomplete="name" />
<input type="email" id="email" autocomplete="email" />
<input type="tel" id="phone" autocomplete="tel" />

Testing Your Forms

The fastest way to audit form accessibility: use the ADA Compliance Checker extension to automatically detect unlabeled inputs and missing fieldset/legend groupings. Then test manually by tabbing through the form, submitting it with errors, and navigating with a screen reader to verify error announcements.