git:20260721.1f8595d to git:20260728.fac4544

---

name: accessible-forms

description: Build forms with associated labels, identified errors, clear instructions, and autocomplete attributes. Use when creating or auditing forms for accessibility.

---

# 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,

- 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.