Blog

ARTICLE

Accessible Forms: Best Practices for Inclusive User Input

Forms are where things get real. Signing up, logging in, checking out, submitting a request — these are not optional parts of the experience, they are the experience. And yet forms are consistently among the most poorly accessible parts of websites and applications. The problems are usually not complicated, which makes it all the more frustrating when they keep appearing.

Labels are non-negotiable

Every field needs a visible, persistent label — not a placeholder, not a tooltip, a real label that stays visible while the user types:

  • Use a proper HTML <label> element connected to its input via the for attribute. Visual proximity is not enough for screen readers.
  • Place labels above the input field — it works better on mobile, it survives zoom, and it is easier to read.
  • Write labels in plain language without abbreviations or jargon.
  • Mark required fields with the word “required” — not just an asterisk. If you do use an asterisk, explain it at the top of the form.

Error messages that actually help

Telling someone their input is “invalid” is not useful. Telling them exactly what went wrong and how to fix it is:

  • Be specific — “Password must be at least 8 characters” is far more helpful than “Password is too short”.
  • Place the error message next to the field it relates to, not only in a summary at the top of the page.
  • Use text and icons to communicate errors, not color alone — a red border without a message fails users with color blindness and screen reader users alike.
  • Make error messages programmatically associated with their fields using aria-describedby, so screen readers announce them when the field receives focus.
  • When errors occur, move focus to the error summary or the first problem field so keyboard and screen reader users land in the right place.

Everything must work by keyboard

If a user cannot complete your form without a mouse, it is not accessible. This is also a good general usability test — if keyboard navigation feels awkward, something is probably wrong with the interaction design:

  • Every field, button, checkbox, radio button, and dropdown must be reachable and operable with the Tab key.
  • Focus should move in a logical order — generally top to bottom, left to right.
  • Custom controls like date pickers and autocompletes need to implement ARIA roles and keyboard patterns correctly — the ARIA Authoring Practices Guide is the reference.
  • Focus indicators must be clearly visible on every interactive element. Never remove the outline without providing an equally strong alternative.

Group related fields properly

Context matters, especially for screen reader users who encounter fields one at a time and do not have the visual overview sighted users take for granted:

  • Use <fieldset> and <legend> to group related controls — radio buttons, checkboxes, date fields. The legend is announced before each field within the group.
  • For multi-step forms, clearly communicate which step the user is on and how many remain.
  • Group date fields (day, month, year) with a legend like “Date of birth” so every individual field has context.

Placeholder text is not a label

This one is worth being direct about: placeholder text is not a substitute for a label, and using it as one causes real problems:

  • Placeholder text disappears as soon as typing begins — users forget what was asked.
  • Its contrast is typically too low to meet accessibility standards.
  • Some assistive technologies do not reliably read placeholder text as a label.
  • Use placeholder text only for hints or examples (e.g., “e.g., name@email.com”), never as the primary label.

Respect users’ time and cognitive load

Not every user can complete a form quickly. Cognitive disabilities, anxiety, and attention difficulties all affect how people interact with forms — and the design choices you make can either help or hinder:

  • Avoid unnecessary time limits. If a session timeout is required for security, warn users and let them extend it.
  • Break long forms into clearly labelled steps with a progress indicator.
  • Show a review step before final submission so users can catch mistakes.
  • Support browser autocomplete with the correct autocomplete attribute values — it reduces the burden on users with memory difficulties.
  • Save progress where possible so users are not penalised for taking a break.

Small changes, real difference

Most accessible form design comes down to a handful of consistent decisions — real labels, useful error messages, keyboard operability, sensible grouping. None of these are particularly difficult to implement. The impact on users who need them is significant, and the side effect is that your forms become more usable for everyone else too.

Feb 27, 2026

3 min read