Accessible forms: labels, errors and keyboard

What makes a form accessible?

Forms are often the point where a website fulfils its purpose: getting in touch, ordering, signing up, applying. If someone fails here, the whole journey ends. Good forms help not only screen reader users, but also people with learning difficulties, older people and anyone typing on a smartphone on the go.

An accessible form has visible labels that are also connected in the code, clear instructions and helpful error messages, and it can be operated entirely by keyboard. In WCAG, this mainly concerns criteria 1.3.1 (structure), 2.1.1 (keyboard), 3.3.1 to 3.3.3 (errors, labels, error suggestions) and 4.1.2 (name, role, value).

How do I label form fields correctly?

Link every input field to a label using matching for and id values, for example <label for="email">Email address</label> and <input id="email" type="email">. The screen reader then reads out the label, and clicking the label puts the focus in the field.

A placeholder disappears as you type and is no substitute. The accessible name should also contain the word that is visible. Someone using voice control who says ‘Click Email address’ must be able to reach the field that way. Buttons also need clear text such as ‘Send message’ rather than just an arrow.

If a visible label is left out for design reasons, for example on a search field with a magnifying glass, the field still needs an accessible name, for example via a visually hidden label or aria-label. Visible text remains the better solution because it helps everyone. For text fields, the label usually sits above or to the left; for checkboxes and radio buttons, to the right.

How do I mark required fields?

Explain at the start how you mark required fields, for example ‘Fields marked * are required’. Adding ‘(required)’ to the label is even clearer. The HTML attribute required also passes the information on to assistive technologies.

Do not mark required fields only with colour. State expected formats before people enter anything, for example ‘Date in the format DD.MM.YYYY’. Only ask for information your process really needs. If almost all fields are required, it is better to mark the few optional ones with ‘(optional)’.

When do I need fieldset and legend?

When several fields belong together, you group them with fieldset and give the group a heading with legend. Typical examples are radio buttons such as ‘Preferred contact method: phone, email’ or groups of checkboxes.

Without a group label, a screen reader user only hears ‘Phone, radio button’ and does not know what the question refers to. Address blocks such as delivery and billing address also become clearer with groups. But do not nest groups unnecessarily, because some screen readers read the group label out with every field.

How do I write helpful error messages?

Validate input on submission or when a field is left, not on every keystroke. Messages that appear while people are still typing constantly interrupt screen reader users. After submission, move the focus to the error summary or the first field with an error, so that nobody has to search.

1. 1Name the affected field and the specific cause: ‘The email address does not contain an @ sign.’
2. 2Describe a possible correction, such as the expected date format.
3. 3Mark errors with text, not only with red colour.
4. 4Connect error text and additional hints to the field in the code, for example via aria-describedby.
5. 5If there are several errors, a summary above the form with links to the fields helps.
6. 6Keep data that has already been entered, as far as the process allows.
7. 7Announce status messages such as ‘Message sent’ so that screen readers read them out without moving the focus (WCAG 4.1.3).

How does autocomplete help people fill in forms?

With the autocomplete attribute, you tell the browser which information a field expects, such as autocomplete="name", "email" or "postal-code". At level AA, WCAG 1.3.5 requires the purpose of such fields collecting information about the user to be programmatically determinable.

The browser can then fill in the fields automatically. This saves typing and helps people with motor or cognitive impairments. In the same spirit, WCAG 2.2 criterion 3.3.7 requires that information already entered in the same process does not have to be typed in again. Do not block autofill with autocomplete="off" without good reason.

What applies to time limits, CAPTCHAs and login?

If a form times out, users must generally be able to turn off, adjust or extend the limit (WCAG 2.2.1). Otherwise it is precisely people who type more slowly who lose their input. State in advance how much time is available.

For login, WCAG 3.3.8 prohibits cognitive function tests such as puzzles or retyping distorted characters if there is no alternative or help. Allow passwords to be pasted and password managers to be used. Split long forms into steps and show progress.

For orders and other submissions with legal or financial consequences, WCAG 3.3.4 requires that the submission can be reversed, that input is checked, or that a review before submission allows corrections.

How do I test a form?

Reach the fields and the submit button with the keyboard. Deliberately submit incomplete information and correct the error. Then check whether a success message is recognisable. Include fields that appear dynamically and repeat the journey with a screen reader. Make sure the focus order follows the visual order, especially in two-column forms.

Among other things, the Accessonaut check finds unlabelled form fields automatically. It does not assess whether instructions and error messages are understandable; for that you need the manual walkthrough.

Also check at 200 per cent zoom that labels and error messages stay visible next to their fields. On a smartphone, suitable input types such as type="email" or type="tel" help, because the on-screen keyboard then offers the right characters.