Form labels

A text box next to the word "Email" is not labelled until the label element is tied to it; until then a screen reader may say only "edit text".

Every field needs a name

When focus lands on a form field, a screen reader announces its label, its type and its state: "Email, edit text, required". The label comes from a label element tied to the field. There are two ways to tie them. Give the input an id and the label a matching for, or put the input inside the label. Either way, clicking the label text also moves focus into the field, which makes small checkboxes and radio buttons much easier to hit.

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

<label>
  <input type="checkbox" name="news"> Send me the weekly menu
</label>

WCAG 2.2 success criterion 3.3.2 Labels or Instructions, at level A, asks for labels or instructions whenever content needs user input, and 1.3.1 Info and Relationships asks that the link between label and field exists in the code, not only on screen. A paragraph that happens to sit above an input is only visually close; nothing tells assistive technology that the two belong together.

Placeholders are not labels

The placeholder attribute shows grey hint text inside an empty field. It is tempting to use it instead of a label, and many sign-up forms do. The trouble is that it disappears as soon as you type, so you cannot check what the field was for, and it is usually pale enough to fail the contrast rules from the previous unit. Use a visible label and, if you like, a placeholder with an example value as well.

Groups, purpose and errors

Radio buttons and related checkboxes need a group label too. Wrap them in a fieldset and put the question in its legend, so a screen reader says "Size, group" before "Small, radio button, 1 of 3". For personal details, the autocomplete attribute tells the browser what a field is for, using names from the HTML standard such as name, email, tel, new-password and one-time-code. Criterion 1.3.5 Identify Input Purpose, at level AA, asks for exactly this, because it lets browsers fill fields in and lets some tools show familiar icons next to them.

When something goes wrong, say so in words. Criterion 3.3.1 Error Identification asks that an input error is identified and described to the user in text, not only by turning the border red. WCAG 2.2 also added 3.3.7 Redundant Entry: information a person already entered in the same process should be filled in again for them or offered to select, instead of being typed twice. And 3.3.8 Accessible Authentication (Minimum), at level AA, says a login step must not depend on remembering or transcribing something unless help is available; letting password managers fill the field and allowing paste both count as that help.

Say what is needed before people start

Instructions belong before the fields they describe, not in an error message after someone has failed. If a password must be at least 15 characters, say so next to the label. Mark required fields in the label text, for example with the word "required", and add the required attribute so the browser also announces it. When an error message appears, keep it next to its field and tie the two together with aria-describedby pointing at the message's id; the screen reader then reads the message when the field gets focus. Finally, move focus to the first field with a problem, or to a summary of the errors at the top, so a keyboard user is not left at the bottom of a long form wondering what happened.