3.3.2 Labels or Instructions (Level A)
High-Level Description
This success criterion ensures that users receive clear labels or instructions when interacting with input fields. It helps users understand what information is expected and how to provide it correctly, reducing confusion and form errors.
Detailed Description
Applies to:
- All form inputs - text fields, checkboxes, radio buttons, and dropdowns.
- Interactive elements requiring user decisions, such as captchas and file uploads.
- Multi-step forms or processes.
This allows:
- Users to provide accurate information the first time.
- Screen readers to announce meaningful context for each input.
- People with cognitive, language, or memory difficulties to better understand form requirements.
Indicators of Non-Compliance:
- Form fields are missing visible or programmatic labels e.g. asterisks (*) or ‘required’ in the visible label and aria-required in the programmatic label.
- Input requirements, such as format or character limits are not explained.
- Placeholder text is used as the only method of labelling.
- Radio buttons or checkboxes lack a visible group label.
- Screen reader users are not told what each input is for.
Real World Examples
| Scenario | Non-Compliant | Compliant |
|---|---|---|
| Email input | No label or only a placeholder (“Enter email”). | Label reads “Email address” with format guidance if needed. |
| Date of birth field | Field accepts DD/MM/YYYY but no instructions provided. | Label reads “Date of Birth” with text: “Format: DD/MM/YYYY”. |
| Phone number field | No indication of whether international code is required. | Label includes “Phone (include country code)”. |
| Required fields | No asterisk (*) or instruction about required vs. optional. | Instructions state “Fields marked with * are required”/ |
| Checkbox group | No label explaining the group context. | Fieldset with legend: "Choose your preferred contact methods". |
Disability Impact
| Disability Group | Without Compliance | With Compliance |
|---|---|---|
| Screen Reader Users | Can't tell what a field is for or if it lacks an associated label. | Accessible labels are announced, enabling successful form completion. |
| Cognitive Disabilities | May misunderstand vague or missing instructions. | Clear labels and examples improve comprehension. |
| Low Vision Users | Placeholder-only labels disappear when typing, causing confusion. | Persistent visible labels ensure clarity. |
| All Users | Form inputs become trial-and-error tasks. | Instructions reduce mistakes and speed up the process. |
Supporting Documentation
- WCAG 2.2 Success Criterion 3.3.2 - Labels or Instructions
- G131 - Providing descriptive labels
- ARIA Best Practices – Labeling Controls
Remediation Strategies
1 - Always Use Explicit Labels
Ensure each input has a clear and visible label:
< label for="email" >Email Address< /label >
< input type="email" id="email" name="email" >
2 - Avoid Placeholder-Only Labels
Placeholder text should supplement, not replace labels:
< label for="phone" >Phone Number< /label >
< input type="tel" id="phone" name="phone" placeholder="Include country code" >
3 - Use ARIA When Visual Design Limits Labels
If visible labels are restricted by design, use aria-label to ensure accessibility.
Use the ‘aria-required’ attribute to ensure required fields are flagged accurately.
< label for="email" >Email Address< /label >
< input type="email" aria-required=”true” id="email" name="email" >