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
Ready to start fixing missing labels on your website? Here are a few methods to implement:
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.
For instance, instead of saying “Password,” you should say “Password (Minimum 8 characters, including one number)”
Dates are also an important element and should be displayed like this: Date of Birth (DD/MM/YYYY).
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, we recommend running an accessibility scan again to confirm there are no longer WCAG 3.3.2 issues. You can also test this with a screen reader or by using your keyboard to navigate.
Other questions to ask include:
- 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
If you’re ready to take the first steps toward WCAG 3.3.2 compliance, this checklist will help:
- 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 FAQs
Looking for a quick recap? Here are answers to some of the most frequently asked questions on this topic:
WCAG 3.3.2 requires that labels or instructions are provided whenever user input is required so users understand what data to enter.
No. Placeholder text disappears when typing begins and does not reliably function as an accessible label.
Labels must be programmatically associated. Visually hidden labels can be acceptable if implemented correctly, but visible labels are strongly recommended.
Yes. Required fields must be clearly identified, and instructions must be provided if specific formatting is expected.