Accessible forms
An accessible form ties each field to an explicit label, signals errors clearly and avoids asking for the same information twice. It improves completion rates for everyone.
The key rules
- Explicit labels:
<label for="id">linked to each field. - Instructions before the field, not only after.
- Errors: precise text message linked to the field with
aria-describedby, announced viarole="alert"or anaria-liveregion. - Grouping:
<fieldset>and<legend>for dates, addresses, multiple choices. - Autofill: an
autocompleteattribute matching each field’s purpose. - CAPTCHA: offer an alternative; WCAG 3.3.8 forbids cognitive tests with no replacement.
Code example
<label for="email">Email address</label>
<input id="email" name="email" type="email" autocomplete="email"
aria-describedby="email-err" aria-invalid="true" required>
<p id="email-err" role="alert">Enter a valid address, for example name@example.com.</p>How to test
Navigate by keyboard, listen to announcements with NVDA or VoiceOver, submit the form empty, then with errors. Log in with a password manager. RGAA criteria: 11.1, 11.2, 11.5, 11.6, 11.10, 11.13.
Frequently asked questions
Should required fields be indicated?
Yes, in text (“required”) and with the required attribute, without relying on colour or an unexplained asterisk alone.
Can a placeholder be used as a label?
No: it disappears on input, its contrast is often insufficient and it is not a reliable substitute for a visible label.