7 Form Accessibility Mistakes (and WCAG Fixes)

Forms are where users get real work done - signing up, checking out, applying, booking, and everything in between. When a form isn't accessible, people don't just get frustrated; many are locked out of the product entirely. The good news: most form accessibility issues come from a small handful of repeat offenders, and each one has a clear fix.

Here are seven of the most common mistakes we see in AccessGuard audits, along with practical ways to fix them.

1. Missing or improperly associated labels

Every input needs a visible, programmatically associated label. Screen readers rely on that association to announce what the field is for. A nearby piece of text isn't enough - the <label> must be tied to the input.

Fix: Use <label for="email">Email</label> with a matching id="email" on the input, or wrap the input inside the <label>.

2. Using placeholder text as a label

Placeholders disappear as soon as the user starts typing, have poor contrast by default, and aren't consistently announced by assistive technologies. They're hints, not labels.

Fix: Always pair a persistent visible label with the input. Use the placeholder only for example formats like "[email protected]".

3. Signalling errors with color alone

A red border tells a sighted user something is wrong, but conveys nothing to users with low vision, color blindness, or screen readers. Color should reinforce meaning, not carry it alone.

Fix: Combine color with an icon, a clear text message, and a programmatic association via aria-describedby so the error is announced when the field gets focus.

4. Error messages that screen readers never hear

Inline validation often updates the DOM silently. A sighted user sees the message appear; a screen reader user has no idea anything changed.

Fix: Mark invalid fields with aria-invalid="true", connect them to their error text with aria-describedby, and put summary messages in a live region (role="alert" or aria-live="polite").

5. Missing autocomplete attributes

The autocomplete attribute isn't just a convenience - it's a WCAG 2.1 success criterion (1.3.5) and a huge help for users with motor or cognitive disabilities who rely on browser autofill.

Fix: Add the appropriate tokens, such as autocomplete="email", autocomplete="given-name", or autocomplete="postal-code", to every applicable field.

6. Keyboard traps in custom controls

Custom date pickers, combo boxes, and modal dialogs frequently trap keyboard users or skip focus in unexpected ways. If a user can't Tab in and Tab back out, the control is broken.

Fix: Test every custom widget using only the keyboard. Follow the ARIA Authoring Practices patterns, manage focus explicitly when dialogs open and close, and return focus to the triggering element on dismiss.

7. Unclear required-field indication

A lone red asterisk is easy to miss and often isn't announced. Users shouldn't have to guess which fields are mandatory or discover it only on submit.

Fix: Use required (or aria-required="true" for custom controls), include the word "required" in the visible label or helper text, and explain what the asterisk means at the top of the form.

A quick self-check

Before shipping your next form, run through this short list: every field has a real label, errors are announced and not color-only, autocomplete is set, the entire flow works with keyboard only, and required fields are obvious both visually and programmatically. Nail those five things and you're ahead of the vast majority of forms on the web.

Accessible forms aren't a separate, heavier version of your product - they're simply better forms. Everyone benefits: faster autofill, clearer errors, fewer abandoned submissions, and a product that works for more of the people you're building for.