This article provides a practical, developer-focused guide to WCAG 3.3.2 (Labels or Instructions). It explains what the success criterion requires, why it matters for accessibility, and how to implement it correctly using clear labels, helpful instructions, and proper markup.
WCAG Principle: Understandable
Guideline 3.3: Input Assistance (Help users avoid and correct mistakes)
Conformance Level: A (Minimal Requirement)
What is Success Criterion 3.3.2?
Labels or instructions are provided when content requires user input.
This success criterion ensures that websites provide clear, useful guidance when users fill out forms. It applies to text fields, dropdowns, checkboxes, and any other input elements where users must enter or select data. For example, if a field requires a specific format (like MM/DD/YYYY for dates or a phone number with a country code), explain it upfront before users type. Otherwise, they may get confused and make mistakes. The goal is to make forms intuitive for everyone and prevent user error before it happens.
Why this matters for accessibility
According to the WebAIM Million 2024 report, missing form labels are the third most common accessibility issue on homepages. When form labels or instructions are unclear, users may struggle to understand what’s required, leading to mistakes, frustration, or abandonment. This especially affects people with visual, cognitive, or motor disabilities who rely on screen readers, voice input, or keyboard navigation.
For example, screen readers rely on properly associated labels to understand and describe input fields. Without them, a screen reader may announce a field as “edit text blank,” leaving users confused. Similarly, people with cognitive disabilities may struggle with complex forms if instructions are missing or unclear.
Therefore, proper labeling and instructions improve accessibility in several ways:
- Screen reader users hear clear field descriptions rather than confusing or missing labels.
- Keyboard users navigate forms efficiently without needing to click around for missing information.
- Users with memory or cognitive challenges easily understand input expectations.
- All users complete forms faster and with fewer mistakes.
How to Meet Success Criterion 3.3.2
Common WCAG 3.3.2 errors on websites:
- Using placeholder text instead of a visible and programmatic label. As a result, the placeholder text disappears when users type, and screen readers don’t recognize it as a label.
- Labels exist but are not linked to their corresponding input fields using for attributes or ARIA associations.
- Forms with generic or vague labels like “Enter here” or “Input,” which don’t clearly describe what users should enter.
- Required fields are marked with color or an asterisk (*) but lack a textual explanation for assistive technology users.
- Multiple fields use the same label (e.g., two “Name” fields for first and last name) without additional clarification.
- Poor CSS styling causes labels to overlap with input fields, making them hard to read or interact with.
How to fix these errors:
- Always use a visible <label> element outside the input field to ensure screen readers recognize and announce it properly.
- Explicitly associate labels with their input fields using the for attribute in HTML or aria-labelledby in complex UI components.
- Write meaningful labels that accurately describe expected input. Instead of vague terms like “Enter here,” specify the purpose, such as “Phone Number (Include country code).”
- Mark required fields with both visual and textual indicators. For instance, instead of relying on color or asterisks alone, include a clear message like, “Fields marked with * are required.” Use aria-required=”true” for screen reader support.
- Differentiate fields with unique labels or additional context. For example, instead of using “Name” twice, separate them into “First Name” and “Last Name” or group related fields using <fieldset> and <legend>.
- Ensure CSS styling does not obscure labels by maintaining proper spacing, alignment, and contrast for readability and usability. Also, check form layouts in different zoom levels and device widths to prevent misalignment.
Helpful tips for developers:
- Test form labels in both focus mode and browse mode. Screen readers behave differently in each mode, so ensure labels work consistently in both.
- Ensure that label focus states are keyboard accessible and screen readers announce the correct label when the field receives focus.
- Use Chrome DevTools to inspect form elements in the Accessibility tree to confirm that labels are correctly mapped to input fields. Automated accessibility tools like Equally AI or WAVE can also help you identify label association that may not be visually obvious.
How to test if your site meets WCAG 3.3.2 conformance
- Conduct screen reader testing with NVDA, JAWS, or VoiceOver to navigate the form and confirm that it announces labels correctly.
- Manually review form fields to ensure users get clear guidance before entering information, especially for required or formatted inputs.
- Use browser extensions like Web Disability Simulator to check if users with low vision and color blindness can still distinguish required fields and instructions.
- Verify that labels remain visible after users start typing and do not rely on disappearing placeholders.
- Increase browser zoom to 200% and check if labels remain visible, readable, and correctly positioned next to their inputs.
- Adjust viewport sizes and test on different screen resolutions to confirm labels remain intact without colliding with input fields.
Bad and Good Examples (Code Snippets)
Code example that fails success criterion 3.3.2
Code Snippet
<form>
<input type="text" placeholder="Full Name" aria-label="Full Name">
<input type="email" placeholder="Email" aria-labelledby="email-desc">
<span id="email-desc" hidden>Enter a valid email</span>
<input type="password" placeholder="Password" aria-hidden="true">
<button type="submit">Sign Up</button>
</form>
The code snippet for this form appears accessible at first glance but still fails WCAG 3.3.2 in multiple ways. First, it uses ARIA attributes incorrectly instead of proper <label> elements, making field associations unreliable for screen readers.
The first input relies on aria-label, but screen readers often ignore placeholders, and without a visible label, sighted users with cognitive disabilities may also struggle. The second input attempts using aria-labelledby but references a hidden element, which screen readers may skip or fail to announce.
Finally, the password field uses aria-hidden=”true”, which removes it from the accessibility tree, making it completely invisible to assistive technology.
Code example that meets success criterion 3.3.7
Code Snippet
<form>
<label for="full-name">Full Name</label>
<input type="text" id="full-name" name="full-name" required>
<label for="email">Email Address</label>
<input type="email" id="email" name="email" aria-describedby="email-desc" required>
<span id="email-desc">Enter a valid email address (e.g., user@example.com)</span>
<label for="password">Password</label>
<input type="password" id="password" name="password" required aria-describedby="password-desc">
<span id="password-desc">Must be at least 8 characters long</span>
<button type="submit">Sign Up</button>
</form>
Now, observe the code snippet for this form. You’ll see that each input field has a visible <label>. This makes it easy for screen readers and sighted users to understand what to enter. The email and password inputs also include aria-describedby, ensuring screen readers properly announce extra instructions, like formatting rules. This approach helps users understand input requirements upfront, reducing errors.
Also, you’ll observe that the form doesn’t rely on ARIA to “fix” missing labels or use placeholders as a substitute for real guidance. Instead, it follows native HTML best practices, making it easy to navigate, understand, and complete—whether a user is sighted, using a screen reader, or relying on a keyboard.
Frequently Asked Questions
Does using a placeholder as a label comply with WCAG 2.2?
No, placeholders alone do not meet WCAG 3.3.2. Placeholders disappear when users type, making it impossible to review input. Screen readers also do not consistently announce placeholders, leaving assistive technology users without essential context. Always use a visible <label> to ensure accessibility.
How should I mark up a label to meet WCAG AA?
Use a <label> with a for attribute that matches the id of the corresponding input field. This ensures the screen correctly announces it (and its clickable associations). For example:
<label for="email">Email Address:</label>
<input type="email" id="email" name="email">For checkboxes and radio buttons, wrap the input inside the <label> or use a <fieldset> and <legend> for grouped inputs.
Do I need to use aria-label on elements that have visible labels?
No, you should not use aria-label when a visible <label> exists. Screen readers will ignore the visible label if aria-label is present, which can lead to confusion. The accessibility best practice is to use aria-label only when a visible label is not possible.
Are multiple form fields in one row ever good for accessibility?
It depends. Fields like date of birth (MM/DD/YYYY) or phone numbers may be grouped in a single row if they are properly structured. Use a <fieldset> with a <legend> to provide context, and ensure each field has an associated <label>. However, placing multiple unrelated fields in one row can confuse users and make navigation difficult, especially for screen readers and keyboard users.
What’s the difference between WCAG 3.3.2 and WCAG 1.3.1 for form labels?
WCAG 1.3.1 (Info and Relationships) ensures labels are properly structured and associated with their inputs. On the other hand, WCAG 3.3.2 (Labels or Instructions) ensures users actually receive clear guidance before entering data. So, a form could pass WCAG 1.3.1 but fail WCAG 3.3.2 if labels exist but do not provide meaningful instructions.
