WCAG 2.1 · Level A · Understandable
WCAG 3.3.2 — Labels or Instructions, explained with examples
Labels or instructions must be provided when content requires user input. Placeholder-only inputs lose their label as soon as the user starts typing — and screen readers vary on whether they announce them at all. Visible labels are the WCAG-compliant default.
- Number
- 3.3.2
- Level
- A
- Principle
- Understandable
- Guideline
- 3.3 Input Assistance
Why this criterion exists
Placeholder-only inputs lose their label as soon as the user starts typing — and screen readers vary on whether they announce them at all. Visible labels are the WCAG-compliant default.
If you only remember one thing: labels or instructions must be provided when content requires user input. Everything else on this page is detail.
Who feels it when this fails
Accessibility criteria sometimes feel abstract until you see who pays the cost when a site ignores them. Labels or Instructions affects:
Screen reader users
Cognitive accessibility
Voice control users
How sites typically fail it
These are the patterns we see week after week. None are intentional — they are accidents of how teams build interfaces under deadline. Knowing the failure modes is the fastest path to writing them out of your component library.
Placeholder used as label
Required-field markers shown only with color
Date format unstated
How to test for it
Empty every input; the label must remain visible.
Automated scanners catch this criterion most of the time, but never all of the time. Manual testing with the keyboard and a screen reader closes the gap.
A code fix you can copy
Visible label, programmatic association, accessible required marker — all three together.
The problem
<input type="email" placeholder="Email">The fix
<label for="email">Email <span aria-hidden="true">*</span><span class="sr-only">(required)</span></label>
<input id="email" type="email" required>Visible label, programmatic association, accessible required marker — all three together.
Frequently asked questions
Can a placeholder serve as a label under 3.3.2?
No. Placeholder text is explicitly not a label under WCAG 3.3.2. Placeholder disappears as soon as the user begins typing, which fails users with cognitive disabilities who need the reminder of what they are filling in. Placeholder text is also lower-contrast than body text by default (failing 1.4.3), and many screen readers in forms mode do not reliably announce it.
How do I mark required fields without relying on color?
The most robust pattern: add an asterisk (*) as a visible indicator, a visually-hidden "(required)" text for screen readers, the required HTML attribute on the input, and a note at the top of the form explaining the asterisk convention. Never rely on a red asterisk alone — red is a color, not a text label.
Does date format need to be stated in the label?
Yes, if the input accepts a date in a specific format. Under 3.3.2, inputs that require data in a particular format must state that format, either in the label or in a visible instruction nearby. "Date of birth (DD/MM/YYYY)" satisfies the criterion; "Date" does not. If you use a native date picker, the format is handled by the browser and no instruction is needed.
Other Understandable criteria
3.1.1 Language of Page
Understandable · Level A
3.3.1 Error Identification
Understandable · Level A
3.2.1 On Focus
Understandable · Level A
3.2.2 On Input
Understandable · Level A
All WCAG 2.1 criteria
Browse the full index by principle
Complete WCAG 2.1 guide
POUR principles, conformance levels, legal requirements
How to fix: form fields without labels
Fix recipe · 3.3.2, 1.3.1, 4.1.2
How to fix: placeholder used as label
Fix recipe · 3.3.2
Find every accessibility issue on your site in 60 seconds.
Free public scan. No card. AI-generated fixes for every issue we find.