Accessible forms: labels, hints and error messages

Six success criteria for forms

WCAG 2.2 is the current W3C Recommendation for accessible web content. For the texts of a form, six of its success criteria matter most:

• 1.3.1 Info and Relationships (level A): what the layout shows, such as which label belongs to which field, is also available in the code or in text.
• 1.3.5 Identify Input Purpose (level AA): fields that ask for information about the user, such as name or email, expose their purpose in the code.
• 3.3.1 Error Identification (level A): if an input error is detected automatically, the field is named and the error is described in text.
• 3.3.2 Labels or Instructions (level A): labels or instructions are provided when content requires user input.
• 3.3.3 Error Suggestion (level AA): if an error is detected and a correction is known, it is suggested, unless this would put the security or the purpose of the content at risk.
• 4.1.2 Name, Role, Value (level A): every control has a name and a role that software can read.

Every field needs a visible label

A label says what belongs in the field, and it stays visible while the user types. In HTML, connect the label element with the field: the for attribute of the label has exactly the same value as the id of the field. Screen readers then read the label with the field, and a click on the label puts the cursor into the field. A button gets its label from its text, and 'Send message' says more than 'Submit'. Labels usually sit to the right of radio buttons and checkboxes and to the left of or above other fields; labels above fields need less space in width.

A placeholder is not a label

The grey text inside an empty field looks like a label, but it is not one. The W3C names the problems:

• It disappears as soon as someone types, so it is harder to check the entries before sending.
• Browsers often show it in a light colour with too little contrast.
• Screen readers do not treat it as a label, and support varies.

Use a placeholder at most for an example, and put everything important into the label or a hint.

Hints and required fields

• Put rules into a hint: the date format, the length of a customer number, what a password needs. In HTML you can connect the hint with aria-describedby, so screen readers read it after the label.
• Say which fields are required and which are optional. If you use an asterisk, explain it once at the start of the form.
• Put instructions for the whole form before the form, for example about a time limit.
• Keep hints short. Too many instructions make a form harder, not easier.

Group related fields

Radio buttons and checkboxes that belong together are grouped with the fieldset element, and the legend element names the group, for example 'How should we contact you?'. The W3C says that radio button groups should always be grouped this way. Keep the legend short, because some screen readers read it with every field. Groups also help with fields that have the same label, such as the street in a shipping and in a billing address.

autocomplete: let the browser help

For fields that ask for information about the user, 1.3.5 asks that their purpose can be determined in the code. WCAG 2.2 has a list of these purposes, based on the autofill section of the HTML specification, such as name, given-name, family-name, email, tel, street-address and postal-code. In HTML you set them with the autocomplete attribute, for example autocomplete="email". Browsers can then fill in saved values, which saves typing. Fields that are not about the user need no purpose.

Error messages that help

An error message has three jobs: name the field, say what is wrong and say how to fix it. 3.3.1 asks for the first two, in text, so a red border or an icon alone is not enough. 3.3.3 asks for the correction where it is known.

• Show the message next to the field and connect it with aria-describedby, so screen readers read it with the field.
• After sending, show a list of all errors at the top, before the form, under a clear heading. Each entry names the field, the problem and the fix, and links to the field.
• Update the page title too, for example '2 errors – Contact form', and move the focus to the first field with an error.
• Keep what the user has already entered. This is our advice, not a WCAG rule: typing everything again after one mistake makes people give up.

Check your form with Do4U

The tool Form texts checks the texts of a web form. You paste the HTML of the form or give the address of the page, and you can add the error messages your form shows. The code reads every field: its label and where the label comes from, hints, placeholders, required fields, autocomplete values and groups of radio buttons or checkboxes. It finds problems such as a field without a label, a placeholder as the only label, required fields that the text does not mention, missing autocomplete values and vague error messages, each with its success criterion. The AI suggests a clear label, a short hint and an error message that names the field and says how to fix the input. The code checks every suggestion and builds an improved HTML draft from your form.

Do4U finds hints and builds a draft, you check and decide. The tool checks the markup, not your styles, scripts or keyboard use, and it does not tell you whether your form is accessible. Test the improved form with a keyboard and a screen reader.