Form labels
A well-labelled form is one where a user never has to guess what a field is for, what format it expects, or whether they’ve filled it in correctly. Labels, helper text, and validation messages are three different tools — each with a distinct job.
Labels
A label names the field. It should be specific enough that the user knows exactly what to enter, without needing to read the helper text first. Labels are always visible — they sit above the field, not inside it.
- Sentence case. “Consultation title”, not “Consultation Title” or “CONSULTATION TITLE”.
- Noun-first, or noun only. “Email address” not “Please enter your email address”.
- Short. A label is a name, not a description. If you need more than 4–5 words, most of that belongs in helper text.
- Always visible. Labels must be visible at all times — not hidden, collapsed, or replaced by placeholder text.
- Programmatically associated. Every input needs a
<label>element connected viafor/id, or anaria-label. A visible label that isn’t connected in code is inaccessible.
Do
Consultation title
Don’t
Please enter the title of your consultation below
Do
Email address
Don’t
Placeholder text used instead of a label. Disappears on focus and fails accessibility requirements.
Do
Stakeholder organisation
Don’t
Org.
Abbreviations in labels force the user to guess what the field means.
Helper text
Helper text adds context the label can’t carry on its own. It explains format requirements, clarifies what the field will be used for, or flags constraints the user needs to know before they start typing.
The key test: does this add information the user needs, or does it just repeat what the label already says? If it’s the latter, remove it. Unnecessary helper text adds visual noise and trains users to skip it.
- Below the label, above the field — or below the field for short format hints. Be consistent across the form.
- One sentence maximum where possible. If you need two, the field might need rethinking.
- Present tense. “This will be visible to participants” not “This field will be used to display a title to participants”.
- Disappears when not needed. Don’t add helper text to every field — only where it genuinely helps.
Do
Consultation title
This is the title participants will see when they open the consultation.
Don’t
Consultation title
Enter the title of your consultation here.
Restates the label without adding any useful information.
Do
Close date
After this date, participants can no longer submit responses.
Don’t
Close date
Please select the date on which you would like to close this consultation to new responses from participants and stakeholders.
Too long. One clear sentence does the job.
Do
Stakeholder email
We’ll use this to send them consultation invitations.
Don’t
Stakeholder email
Email address
Helper text that just repeats the label adds nothing.
Placeholder text
Placeholder text appears inside the field before the user types. It should never be used as a substitute for a label — it disappears when the user starts typing, and low-vision users and screen readers frequently can’t read it reliably.
Use placeholder text for examples only — showing the user what a valid input looks like when the format might not be obvious. Even then, consider whether a format example belongs in helper text instead, where it remains visible.
- Examples, not instructions. “e.g. sarah.jones@example.com” is a good placeholder. “Enter your email address” is not — that’s a label.
- Low contrast by design. Placeholder text is intentionally muted to signal it’s not real content. Don’t style it like real text.
- Optional. Many fields don’t need placeholder text at all if the label and helper text are clear.
- Never rely on it for critical information. Anything the user must read to complete the field correctly belongs in the label or helper text.
Do
Consultation title
Don’t
Instruction in a placeholder field with no visible label. Inaccessible and fails on focus.
Do
Phone number
We’ll only use this if we need to follow up your response.
Don’t
Phone number
Critical information and instructions inside the placeholder — invisible once the user starts typing.
Required fields
Mark optional fields, not required ones. In most forms the majority of fields are required — so marking each one adds visual noise without adding information. Marking the exceptions (the optional fields) is what’s actually useful: it tells the user something they wouldn’t otherwise know.
- Add “(optional)” as plain text in the label for fields the user doesn’t have to complete.
- Don’t use asterisks to mark required fields — asterisks require a legend to explain them, and when most fields are required they become meaningless noise on every row.
- Never use colour alone to indicate required or optional status — it fails for colour-blind users and fails WCAG 1.4.1.
- If every field in a form is required, don’t mark any of them individually — state it once at the top of the form instead.
Do
Phone number Optional
Optional fields are clearly labelled; required fields are unmarked.
Don’t
Phone number
No indication that this field is optional. User may feel obligated to complete it or be confused when validation doesn’t trigger.
Do
Consultation title
Close date Optional
Don’t
Consultation title *
Close date *
Asterisks on every field with no contextual indication of which fields are optional.
Inline validation and error placement
Validation errors should appear immediately below the field that has the problem — not at the top of the form, not in a toast, and not in a summary that forces the user to scroll to find what’s wrong.
For the content of error messages, see the Error messages page. The placement rules:
- Error message appears below the field, in place of (or alongside) the helper text.
- The field border changes to error state, but colour alone isn’t sufficient — an icon or the error text itself must be present.
- Show errors after the user has left the field or attempted to submit — not while they’re actively typing.
- When a form fails on submit, move focus to the first field with an error so keyboard and screen reader users don’t miss it.
- Keep helper text visible alongside the error where it aids recovery. Don’t hide context the user needs to fix the problem.
Email address
This doesn’t look like a valid email address. Check for missing characters after the @ symbol.
Validation error shown below the field with specific guidance on what’s wrong.
Was this page helpful?