5 Common Accessibility Mistakes in Web Forms and How to Fix Them

Forms power almost every interaction on the web: signups, logins, checkouts, contact pages. Yet they’re also where accessibility breaks most often. A form that’s hard to fill out isn’t just frustrating — it can lock people out entirely. Here are five common accessibility mistakes in web forms and how to fix them.

1. Missing or Incorrect Form Labels

The biggest mistake? No label, or a label that isn’t programmatically linked to the input. Placeholder text is not a label — it disappears on input, leaving screen reader users confused. Always use a <label> element with a for attribute matching the input’s id.

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

If you can’t use a visible label (rarely acceptable), add an aria-label or aria-labelledby. For a primer on ARIA labels, check our Beginner’s Guide to ARIA Labels in HTML.

One subtle but common mistake is using a placeholder as the only label. Placeholders disappear when the user starts typing, so screen reader users lose the context. Even sighted users may forget what the field is for if they’re distracted. If you must keep a placeholder for visual cues, always pair it with a proper label — even a visually hidden one using .sr-only or aria-label.

Another issue: labels that are too generic. “Name” might be fine for a simple form, but if you have separate fields for first and last name, label them “First name” and “Last name” rather than just “Name” with a number. Each label should uniquely identify its input.

When using aria-label, be careful — it overrides the visible label for screen readers, but sighted users still see the visible text. If the visible label is different from the aria-label, confusion follows. Keep them consistent.

2. Poor Color Contrast in Form Fields

Form controls like inputs, checkboxes, and error text need sufficient contrast between text and background — at least 4.5:1 for normal text. Light gray placeholders on white backgrounds are common offenders. Use tools like the WebAIM contrast checker, and see our Color Contrast Ratios: A Practical Developer Guide for a deep dive.

Also ensure focus outlines meet minimum contrast. A blue outline on a blue button is invisible. Use a thick, high-contrast ring — avoid removing outline entirely.

But contrast isn’t just about text. Required field indicators (often a red asterisk) need contrast against the background. A light red asterisk on a white background fails. Use a bold color like dark red or add a text note like “(required)” with good contrast.

Error states also need attention. If you change the border color of an invalid input (say from gray to red), that red must contrast with both the white background and the surrounding elements. Better yet, combine color with an icon or text label so it’s not color-dependent.

And don’t forget disabled inputs. Browsers often render them with low contrast, making them hard to read. If a field is truly disabled, ensure the text still meets at least 3:1 contrast (for large text) or 4.5:1 for normal text. Use a consistent disabled style that users can recognize.

3. Invisible or Missing Focus Indicators

Keyboard users rely on a visible focus ring to know where they are. The classic mistake is outline: none without a replacement. Instead, style the :focus and :focus-visible states explicitly.

input:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

Test by pressing Tab through your form — every interactive element should have a clear focus indicator.

Common pitfalls: using only :focus without :focus-visible means mouse users also see the outline (some find it ugly), but removing :focus entirely breaks keyboard usability. The :focus-visible pseudo-class only shows focus when the user navigates via keyboard — best of both worlds. For older browser support, use both: apply a visible focus style to :focus for keyboard users, but also use :focus:not(:focus-visible) to remove it for mouse users if you prefer.

Another mistake: focus ring colors that blend with the background. A dark outline on a dark button disappears. Use a color that contrasts with both the element and its background. Outline offset helps by adding a gap between the outline and the element, making it more visible.

Some custom components, like dropdowns or modals, need special handling. Ensure the focus indicator appears on the currently focused option, not the container. Use aria-activedescendant to manage focus within a list.

4. Keyboard Traps in Form Widgets

A keyboard trap happens when a user can Tab into a widget but not Tab out. Custom controls like date pickers, dropdowns, or autocomplete fields often forget to handle the Escape key or prevent focus from moving. Always ensure Tab moves focus to the next element, and Escape closes the widget.

For example, in a custom select, trap focus inside the list while open, but release focus back to the trigger when closed. Use aria-activedescendant or standard tabindex management.

Here’s a concrete pattern for a dropdown: when the user opens it, set tabindex="0" on the search input or first option, and tabindex="-1" on all other focusable items inside. Handle Arrow keys to move focus within the list. On Escape or Tab (when shift is not pressed), close the dropdown and return focus to the trigger button. On Shift+Tab, close and focus the previous element.

Test with a screen reader: can you navigate through the entire form without getting stuck? A common hidden trap is a custom checkbox that intercepts Tab key events but forgets to forward them — the user presses Tab but focus doesn’t move. Always pass keyboard events through if the widget is not active.

Also avoid tabindex values greater than 0. They create a confusing tab order that breaks the visual flow. Use the DOM order for tab order, or restructure your HTML.

5. Confusing and Undescriptive Error Messages

When validation fails, generic messages like “Invalid input” help no one. Screen readers may not even hear the error if it’s not programmatically associated with the field. Use aria-describedby to link error text to the input.

<input type="email" id="email" aria-describedby="email-error">
<span id="email-error" role="alert">Please enter a valid email address like user@example.com</span>

Also, list all errors at the top of the form for users who scan. But don’t remove inline errors — that’s critical for context.

A common mistake: only showing error messages after form submission, and not announcing them to screen readers. Use role="alert" or live regions (aria-live="assertive") to ensure errors are read immediately. If you update the page dynamically, move focus to the first error or to an error summary to save the user from scrolling.

Write error messages that tell the user what to do. “Email is required” is better than “Field is required.” “Password must be at least 8 characters with one number” is better than “Invalid password.” Include the format or criteria that failed.

Don’t clear the entire form on error — that forces users to re-enter everything. Keep their input intact and highlight only the fields that need correction. This is a basic usability win that also benefits accessibility.

6. Insufficient Error Prevention for Critical Actions

Some forms have destructive consequences: delete account, submit payment, change subscription. Missing a confirmation step or undo mechanism can cause irreversible harm. For critical actions, always ask for confirmation with a clear description of what will happen.

For example, a “Delete account” button should not immediately remove the account. Show a modal or inline confirmation asking the user to type “DELETE” or click a secondary confirm button. Provide an “Undo” option if possible, especially for actions that aren’t instantaneous.

This is especially important for users with motor disabilities who may accidentally press a button. A confirmation step gives them a chance to catch mistakes. For screen reader users, ensure the confirmation dialog gets focus and is announced — use aria-modal="true" and trap focus inside the dialog until dismissed.

Another technique: use a “undo” banner that appears after an action, with a link to revert. This is common in Gmail and other apps. The banner should be focusable and announced with role="status" or aria-live="polite".

7. Not Grouping Related Controls

When you have a set of radio buttons or checkboxes, they should be grouped semantically with <fieldset> and a <legend>. This tells screen readers that the options belong together. Without the grouping, the user hears each option out of context.

<fieldset>
  <legend>Shipping method</legend>
  <input type="radio" id="standard" name="shipping" value="standard">
  <label for="standard">Standard (5-7 days)</label>
  <input type="radio" id="express" name="shipping" value="express">
  <label for="express">Express (2-3 days)</label>
</fieldset>

Don’t use fieldset for single inputs — it’s overkill. Only for groups of related controls. Also, avoid styling that removes the visual border of the fieldset unless you provide another visual grouping (like background color or spacing). The border is a visual cue for sighted users that the options are related.

For simple groups like a name prefix dropdown (Mr., Mrs., Ms.), a fieldset might be unnecessary if the label is clear. Use your judgment: group when the relationship isn’t obvious from the labels alone.

How to Test Your Forms for These Issues

You don’t need expensive tools. Use a screen reader (VoiceOver on macOS, NVDA on Windows) and Tab through every field. Check that labels are read, focus is visible, and errors are announced. Our guide How to Test Your Site for Accessibility Issues walks through a complete test routine.

Additionally, use the browser’s DevTools to inspect the accessibility tree. In Chrome, open the “Accessibility” tab after selecting an element. Verify that the accessible name matches the label, and that ARIA roles are correct. Check for contrast issues with the built-in color picker or extensions like axe DevTools.

Manual testing is essential. Try navigating your form using only the keyboard (no mouse). Can you complete it without getting stuck? If not, there’s likely a keyboard trap or missing focus indicator. Try using a screen reader with your eyes closed — can you understand the form’s structure and errors? If not, labels or grouping are likely missing.

Finally, test with real users if possible. Nothing beats feedback from people who rely on assistive technology daily. They’ll uncover issues no automated tool can find.

FAQs

Frequently asked questions

What is the most common accessibility mistake in web forms?

The most common mistake is missing or improperly associated labels. Placeholder text is not a substitute for a real label. Screen readers cannot reliably announce placeholder text, and it disappears when the user starts typing, leaving them without context.

How do I fix a keyboard trap in a custom dropdown?

Ensure the dropdown closes when the user presses Escape and focus returns to the trigger button. While the dropdown is open, restrict Tab to elements inside it, but allow Tab to exit when the dropdown is closed. Use JavaScript to manage focus and keydown events.

What contrast ratio should form inputs have?

Text within inputs should have a contrast ratio of at least 4.5:1 against the background. Placeholder text, if used, should also meet this ratio, though it’s better to avoid relying on placeholders alone. Focus indicators should also have good contrast.

Should I use aria-label instead of a visible label?

Generally, no. Visible labels help everyone, especially people with cognitive disabilities and users with memory issues. Only use aria-label when a visible label isn’t possible, such as in icon-only buttons. Always prefer a visible label with a element.

How can I test form accessibility quickly?

Use only your keyboard: Tab through the form, ensure focus is visible, and try submitting with errors. Then turn on a screen reader (NVDA, VoiceOver) and fill out the form again. Check that labels, instructions, and error messages are announced correctly.