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.