Labels and Instructions
Every input needs a persistent label, and format requirements must be stated before the user types.
Definition
WCAG 3.3.2 requires labels or instructions when content requires user input. In practice this means a programmatically associated, visible label on every field, plus any format requirement stated up front.
Craft convention. True because the industry converged on it. Breaking it costs familiarity, not correctness.
On this page
Requirements
- A visible label element associated with the input by its for attribute.
- Format requirements shown before entry, not revealed on failure.
- Required fields marked in text, not by colour or an unexplained asterisk.
- Hint text associated with the field through aria-describedby.
- Autocomplete attributes set correctly, which WCAG 1.3.5 requires for fields collecting user information.
- Groups of related fields wrapped in a fieldset with a legend.
Sources
Where a source establishes something narrower than the popular reading of it, the note says so.
Continue from here
Each link says what the connection is, so you can tell a principle from an alternative from a thing people mix this up with.
Applies when you are designing
Relied on by
Entries that assume this is already in place.
- Error Identification and SuggestionAccessibility
An error that names a field nobody labelled cannot be acted on.
- CheckboxComponent
- Text InputComponent
- AuthenticationPattern
- Input ValidationPattern
- Form Labels and Help TextUX writing
A visible label is both a writing decision and a WCAG requirement.
Related concept
Connected closely enough to change how you apply this.
- Accessible NamesAccessibility
- MicrocopyUX writing