If your website has forms, contact forms, checkout forms, booking forms, login forms, WCAG 3.3.2 applies to you.
In this WCAG Fix It guide, we’re breaking down one of the most common and preventable accessibility failures: missing labels or unclear instructions.
When users don’t know what information is expected in a field, forms become frustrating, confusing, and sometimes impossible to complete. Fixing it is often one of the simplest accessibility improvements you can make.
What Is WCAG 3.3.2?
WCAG 3.3.2 – Labels or instructions require that labels or instructions are provided when content requires user input.
To real world this, if you ask someone to enter information, you must clearly tell them what to enter.
This applies to:
- Text fields
- Email fields
- Password inputs
- Checkboxes
- Radio buttons
- Dropdown menus
- Date pickers
- Search boxes
Every input field must have a visible, descriptive text label.
Why Labels Matter
A label tells users:
- What information is required
- What format to use
- Whether the field is mandatory
- What the field relates to
Without a label, users are left guessing and guessing leads to errors.
The Human Impact of Missing Labels
Imagine navigating a form using a screen reader. You then tab to a field and the screen reader announces:
“Edit text.”
But that’s it, no label, no context, so the user has no clue what to enter.
Now imagine the same form visually. You see a blank box with faint grey placeholder text that disappears as soon as you start typing. Now you can’t remember what the field was asking for.
For users with:
- Cognitive impairments
- Memory difficulties
- Screen magnification
- Assistive technology
Missing labels turn simple forms into barriers, and when users can’t complete forms, they abandon them.
Common WCAG 3.3.2 Failures
Here’s what we typically see when scanning websites:
- Input fields without visible labels
- Placeholder text used instead of a label
- Instructions provided visually but not programmatically associated
- Required fields not clearly marked
- Radio buttons or checkboxes without descriptive group labels
- Date fields with no format guidance
All of these can fail WCAG 3.3.2.
The Key Requirement: Placeholder Text Is Not a Label
This is one of the most important points.
Bad example:
<input type=”text” placeholder=”Enter your email”>
Why this fails:
- Placeholder text disappears when typing begins
- It’s often low contrast
- It may not be read consistently by screen readers
Correct example:
<label for=”email”>Email Address</label>
<input type=”email” id=”email”>
You can still use placeholder text for examples (e.g. name@example.com), but it must never replace a proper label.
How to Fix Missing Labels
Add a Visible Label Element
Every input should have a corresponding <label>:
<label for=”phone”>Phone Number</label>
<input type=”tel” id=”phone”>
This ensures the field has:
- A visible label
- A programmatically associated label
Both are required for accessibility.
Provide Clear Instructions Where Needed
If format matters, tell users upfront.
Instead of:
Password
Use:
Password (Minimum 8 characters, including one number)
If date format matters:
Date of Birth (DD/MM/YYYY)
Clear instructions reduce errors and frustration.
Group Related Inputs Properly
For radio buttons or checkboxes, use <fieldset> and <legend>:
<fieldset>
<legend>Preferred Contact Method</legend>
<input type=”radio” id=”email” name=”contact”>
<label for=”email”>Email</label>
<input type=”radio” id=”phone” name=”contact”>
<label for=”phone”>Phone</label>
</fieldset>
This ensures the group has context.
How to Test WCAG 3.3.2
After fixing labels:
- Re-run your accessibility scan
- Confirm 3.3.2 is no longer flagged
- Navigate the form using only the keyboard
- Test with a screen reader
Ask:
- Does every field announce a clear label?
- Are instructions clear before input begins?
- Are required fields identified?
If yes, you’ve fixed it.
Why WCAG 3.3.2 Matters Beyond Compliance
Clear labels on forms can help all users and drive better performance of organisations:
- Improve form completion rates
- Reduce user errors
- Support screen reader users
- Help users with cognitive impairments
- Improve usability for everyone
- Reduce legal risk
Forms are often where conversions happen. If your forms aren’t accessible, your business isn’t accessible. Small structural improvements to forms have a huge usability impact.
WCAG 3.3.2 Quick Fix Checklist
Every input field has a visible label
Labels are programmatically associated
Placeholder text is not used as a label
Required fields are clearly marked
Instructions provided where format matters
Grouped inputs use fieldset and legend
Forms re-tested after updates
WCAG 3.3.2 Labels or Instructions Frequently Asked Questions
What is WCAG 3.3.2 Labels or Instructions?
WCAG 3.3.2 requires that labels or instructions are provided whenever user input is required so users understand what data to enter.
Can I use placeholder text instead of a label?
No. Placeholder text disappears when typing begins and does not reliably function as an accessible label.
Do hidden labels count for accessibility?
Labels must be programmatically associated. Visually hidden labels can be acceptable if implemented correctly, but visible labels are strongly recommended.
Does this apply to required fields?
Yes. Required fields must be clearly identified, and instructions must be provided if specific formatting is expected.