Forms & inputs

Forms are where users act: they sign in, book, pay, search, and apply. Everything else on a page can be content to read, but a form is a task to complete. When a field has no real label, an error never reaches the people who need it, or related choices aren’t grouped, the task doesn’t just get harder — it becomes impossible, and the user is locked out of the very thing they came to do. Accessible forms are therefore some of the highest-stakes work in the whole discipline.

Who this affects

• Screen reader users rely on a programmatic label to know what a field is for. With no <label>, a field is announced as just “edit text”, and an error spoken only in red text is never heard at all.
• Low-vision and zoom users magnify the page heavily, so a placeholder that vanishes the moment they type, or an error shown far from its field, can scroll completely out of view — they lose the instruction they were following.
• Motor, keyboard, and voice users tab through controls and speak their names to operate them. Clickable text that isn’t a real <label> gives them nothing to target, and ungrouped radios force extra, error-prone steps.
• Cognitive and memory users depend on clear grouping, plain error text that says how to fix the problem, and browser autofill to reduce the load of recalling and re-typing personal data on every form.

Standards covered

The lessons in this category map field-level accessibility to the success criteria and laws that require it. The same fixes satisfy all of them at once.

Lessons

• Accessible forms

  Real labels, associated and announced errors, grouped controls, and correct autocomplete tokens — the four fixes behind most form failures.

  1.3.1 3.3.1 3.3.2 3.3.3 1.3.5 4.1.2 / 4.1.3

• Form validation & error recovery

  Identify errors in text, suggest fixes, and let people review important submissions.

• Required fields, instructions & input purpose

  Mark required fields programmatically, keep instructions visible, and set autocomplete.