WCAG 2.2 - Success Criterion
3.3.2 Labels or Instructions
Description
When user input is required, labels or instructions must be provided to help users understand what is expected. This applies to all form controls and interactive widgets that require the user to enter or select data. Labels must clearly identify what each field expects, and where input format or constraints apply (such as date format, password rules, or character limits), instructions must be provided before or during data entry so users can supply correctly formatted input without trial and error.
How To Test
- Review each form field on the page and confirm it has a visible, persistent label that is not solely placeholder text.
- Check that any required fields are clearly identified as required (by text in the label, not colour alone).
- Review all fields that expect a specific format (dates, phone numbers, postal codes) and confirm the expected format is displayed as visible text near the field.
- Inspect the HTML to verify that labels are programmatically associated with their controls using
<label for="...">oraria-labelledby. - Test with a screen reader (e.g., NVDA or VoiceOver): navigate to each field in forms mode and confirm the field's label and any instructions are announced.
- Confirm that instructions are available before the user needs to enter data, not only after a submission error.
- Check that group-level instructions (such as "Select all that apply") are provided for checkbox groups and radio groups via
<fieldset>and<legend>.
Testing Tools
- NVDA — Free screen reader for Windows. Download, install, and open Firefox to test the demo. Navigate using Tab and arrow keys, and listen to role, name, and state announcements from the page.
- VoiceOver (macOS) — Built into macOS. Enable with Cmd+F5, then open Safari or Chrome to test the demo. Use VO+arrow keys to navigate and hear semantic structure announcements.
- Lighthouse — Browser accessibility audit in Chrome DevTools. Open DevTools (F12), go to Lighthouse, run the audit to identify semantic and labeling issues.
Demo
This input has no <label>. Only placeholder text is provided - it disappears the moment the user starts typing, leaving no indication of what the field expects.
A persistent <label> is linked via for/id and animates above the field on focus or input. Screen readers announce it normally — the visual effect is CSS only.
Code
<!-- ❌ Placeholder is the only label — disappears on input -->
<input type="email" placeholder="Email address">
<!-- No <label> — screen readers may announce nothing --><!-- ✓ Label floats above on focus — SR unaffected via for/id -->
<div class="float-wrap">
<!-- placeholder=" " is the CSS hook for :not(:placeholder-shown) -->
<input type="email" id="email" placeholder=" ">
<label for="email">Email address</label>
</div>Code
The field enforces xx/xx/xxxx format but gives no clue whether to enter day or month first. The user has to guess.
Same format enforced, but a visible instruction tells the user exactly what order is expected — day first, then month, then year.
Code
<!-- ❌ Label present but no format instruction -->
<label for="dob">Date of birth</label>
<input type="text" id="dob" placeholder="Date">
<!-- User must guess the expected format --><!-- ✓ Label + visible format instruction before input -->
<label for="dob">Date of birth</label>
<input type="text" id="dob" placeholder="DD/MM/YYYY">
<span>Format: DD/MM/YYYY (e.g., 15/03/1990)</span>Code
A red asterisk indicates required fields visually, but screen reader users cannot perceive color or symbols. They have no way to know the field is required until after submission fails.
Text label clearly states "(required)" and the input has the required attribute + aria-required. Screen readers announce the requirement when the field is focused.
Code
<!-- ❌ Red asterisk only — not perceivable by screen reader users -->
<label for="name">Name span style="color:red;">*</span></label>
<input type="text" id="name">
<!-- No required attribute or aria-required --><!-- ✓ Text label + required attribute + aria-required -->
<label for="name">Name (required)</label>
<input type="text" id="name" required aria-required="true">
<!-- Screen reader announces both the text label and the required state -->Code
WCAG Techniques
- Failures: F82 (lack of visual and programmatic indication of input requirements), F86 (placeholder as sole label)
- Success Techniques: H44 (using label elements), H71 (providing description for form controls), ARIA14 (using aria-label to provide an invisible label)
Fail Explanation
A form that uses placeholder text alone as a label fails this criterion, because placeholder text disappears when the user starts typing, leaving them without any indication of what the field expects - particularly problematic for users with cognitive disabilities or short-term memory impairments. Similarly, a date field that accepts only a specific format (e.g., DD/MM/YYYY) but does not display that format requirement before submission is a failure, as users cannot know what is expected until they receive an error message after the fact.
Pass Explanation
A form passes when every input field has a persistent, visible label that clearly identifies the field's purpose, and when any format requirements or constraints are provided as visible text associated with the field before the user submits. Labels must be programmatically linked to their controls (via <label for> or aria-labelledby) so screen reader users also receive the information. Required fields should be identified either by the word "required" in the label or by a convention that is explained (e.g., "Fields marked with * are required").
Notes
Placeholder text can supplement a proper label but must never be used as a replacement for one; this is a very common anti-pattern. This criterion focuses on the presence and availability of labels and instructions, while 3.3.1 Error Identification covers what happens after an error has occurred.
Techniques
WCAG techniques used in this demo: H44, H71, ARIA1
Suggested Solutions & References
Curated from 17 real-world audit findings.