WCAG 3.3.2 is a Level A criterion: whenever a page asks people to enter or choose something, it must show labels or instructions that tell them what is expected. In practice that means a visible label on every field, a note on any required format, and a clear way to tell which fields are required.
It sounds obvious, yet it fails all the time. Designers drop labels to make forms look clean, rely on grey placeholder text that vanishes when typing starts, or leave a date box with no hint about the order of day and month.
Quick facts
Level
AAdded in
WCAG 2.0Covers
Text fields, selects, checkboxes, radio groups, date pickers, file uploadsNeeds
A visible label or instruction, plus format and required field hints where relevantNot enough
Placeholder text alone, or a label that exists only in codeFast test
Click into each field and start typing: can you still tell what it is for?
WCAG 3.3.2 in one minute
The criterion has a short text and a narrow goal: when content requires user input, give people enough information up front to fill it in correctly. It does not ask for long help text. A single clear word such as "Email" is often a full pass.
Look at three things for each input:
- What is it? A visible label, or for a group of radio buttons, a visible question.
- How should I write it? A hint for any format your system insists on.
- Do I have to? A clear marker for required fields, or a note saying all fields are required.
The W3C Understanding page on Labels or Instructions lists the techniques W3C considers sufficient.
Common mistakes and what to do instead
| Mistake | Problem for users | Better approach |
|---|---|---|
| Grey hint inside the box, no label above it | The hint disappears as soon as typing starts and is often low contrast | Keep a visible label above the field; use placeholder only for a short example, if at all |
| Search box with no label or button text | Users of voice control and magnifiers cannot tell its purpose | Add a visible "Search" label or a button that says Search |
| Date field with no format | Users guess between day first and month first | Show "DD/MM/YYYY" next to the label, or use three labelled boxes |
| Asterisks with no key | The meaning of the star is unclear | Add "Fields marked * are required" before the form |
| Radio buttons with no question | "Yes" and "No" alone have no meaning | Group the radios with fieldset and put the question in legend |
| Password rules shown only after an error | People fail first and learn later | Show the rules next to the field before typing |
Example markup with a label, hint and required marker
Use a real label element, keep any hint in its own element, and connect the hint with aria-describedby so screen readers read it after the label.
Fails: the only clue disappears once typing starts.
<input type="text" placeholder="Date of birth">Passes: visible label, visible format, required stated in words.
<label for="dob">Date of birth (required)</label>
<p id="dob-hint">Use the format DD/MM/YYYY</p>
<input id="dob" type="text" required aria-describedby="dob-hint">How to check a form against 3.3.2
- Go through the form and highlight every control a user can change.
- For each one, find the visible text that names it. Text that exists only in an
aria-labeldoes not count for sighted users. - Put the cursor in each field and type. If the only label was placeholder text, it is now gone and the field fails in practice.
- Try entering values the system rejects. If the system enforces a format, the hint should have been visible before you typed.
- Look at grouped controls, such as radio buttons and checkbox sets, and confirm there is a visible question for the group.
- Note whether required fields are marked and the marker is explained.
Labels must also be connected in code so assistive technology can find them, but that part is judged under 1.3.1 and 4.1.2. Under this rule you are mainly checking what is on screen.
People who rely on clear labels
Visible labels help nearly everyone, but some groups depend on them:
- People with memory or attention disabilities who forget what a field was for once the placeholder vanishes.
- Screen magnifier users who see only a small part of the form and need the label right beside the field.
- Voice control users who say the label to move into a field, which only works if they can see it.
- Older users and people filling forms in a second language, who need format examples to avoid guessing.
Questions people ask
What does WCAG 3.3.2 ask for?
It is a Level A success criterion that requires labels or instructions whenever content needs user input. Users should know what each field is for, which fields are required and any format the system expects before they start typing.
Does placeholder text pass 3.3.2 WCAG?
Usually not on its own. Placeholder text disappears when typing starts and often has weak contrast, so it fails users who need to check what a field is for. Keep a visible label and use placeholder only for a short example.
Is aria-label enough to meet 3.3.2?
No, not by itself. aria-label gives screen reader users a name, but sighted users still see nothing, and this criterion is about information people can perceive. Use a visible label and connect it in code.
Do I need instructions for every field?
No. A clear label is enough for simple fields like name or email. Add instructions only where users could get it wrong, such as dates, passwords, file types or unusual formats.
How should required fields be marked?
Write "required" in the label, or use an asterisk and explain it at the start of the form. Avoid relying on color alone, since color as the only cue breaks criterion 1.4.1 too.