Accessible forms

Accessible forms

Forms are where users accomplish tasks (sign up, buy, submit), and inaccessible forms block those tasks entirely for some users. The requirements are concrete: every field labeled and associated, every error identified in text, instructions available, and the browser's autofill enabled.

Method

1. Associate a real label with every field. A <label for="email"> tied to the input's id (or wrapping it): so clicking the label focuses the field and the screen reader announces the label when the field gets focus (see aria-usage: prefer real labels to aria-label). Placeholder text is not a label (it disappears on input and often fails contrast: see color-contrast); a field labeled only by placeholder is unlabeled the moment the user types.
2. Identify errors in text, associated with the field. When validation fails: describe the error in text ("Email must include an @"), associate it with the field (aria-describedby pointing to the error message), and move focus to (or announce: see screen-reader-testing's live regions) the first error. Color alone (a red border) does not tell a screen-reader or color-blind user what is wrong (see color-contrast's don't-rely-on-color): the error must be text they can perceive.
3. Provide instructions and requirements up front. Format requirements, which fields are required, and constraints stated before the user submits and fails: "Password must be at least 12 characters" shown with the field, not only in the error after. Required fields marked in text and with aria-required (not by color or an asterisk alone: see the multi-channel rule). Users should know the rules before hitting them.
4. Enable autocomplete and the right input types. autocomplete attributes (autocomplete="email", "name", "one-time-code") let browsers and password managers autofill: a huge help for users with motor or cognitive disabilities, and everyone else (see the autofill discipline in mobile-input-ux). Correct input type (email, tel, number) triggers the right keyboard and validation. These reduce the typing burden that forms impose.
5. Group related fields and controls. Radio buttons and checkboxes for one question grouped in a <fieldset> with a <legend> (so the screen reader announces the group's question with each option); related sections with headings. Ungrouped radio options announce individually with no context ("yes, radio button" with no question) leaving users lost.
6. Keep the submit path clear and forgiving. The submit button reachable and labeled with its action ("Create account", not "Submit"); errors on submit do not clear entered data (see form-handling); success confirmed in a way screen readers announce. A form that clears itself on error or gives no submission feedback fails users exactly at the moment of completing their task.

Boundaries

• Accessible forms combine several techniques (labels, errors, keyboard, focus: see keyboard-navigation, focus- management, screen-reader-testing); a form is accessible only when all hold, and the whole task can be completed with keyboard and screen reader.
• Complex custom form controls (date pickers, comboboxes, multi-selects) need the full ARIA widget patterns (see aria-usage) and are easy to get wrong; prefer native inputs or well-tested accessible libraries over custom ones where possible.
• Client-side validation UX (timing, inline vs on-submit: see form-handling) and accessibility overlap; the accessibility requirements (text errors, association, focus) apply regardless of the validation timing chosen.