Level A Understandable WCAG 3.3.2

What This Criterion Requires

WCAG 3.3.2 requires that labels or instructions are provided when content requires user input. Every form control that expects user input must have a clear, visible label that describes what information is needed, and that label must be programmatically associated with the control so assistive technologies can announce it. This goes beyond just having a label element: the label must provide sufficient instructions for the user to complete the input correctly. If a field expects a specific format (like a date in MM/DD/YYYY format), requires a specific value range, or is conditional on other selections, those instructions must be available before the user submits the form. Required fields must be identified, and the convention used to indicate required status (such as an asterisk) must be explained. Group labels using fieldset and legend should be used for related controls like radio button groups, checkbox groups, and multi-part fields like date of birth or phone number components.

Why It Matters

Forms are the primary way users interact with and provide information to websites. Without clear labels and instructions, users may not know what information to enter, what format to use, or which fields are required. This leads to form submission errors, user frustration, and abandonment. For screen reader users, a form field without a programmatically associated label is completely ambiguous: the screen reader may announce 'edit text' with no indication of what information is expected. Users with cognitive disabilities particularly benefit from clear, upfront instructions because they reduce the cognitive load of figuring out what is expected. Older users who are less familiar with web conventions also rely on explicit instructions rather than implied expectations. When form labels are missing or inadequate, even sighted users make more mistakes, resulting in higher error rates and lower completion rates. Proper form labeling is both an accessibility requirement and a usability best practice that directly impacts conversion rates and user satisfaction.

Common Failures and How to Fix Them

Form input without a programmatically associated label

A text input has a nearby visible label but it is not programmatically associated using the for/id pattern, wrapping label, or aria-labelledby. Screen readers cannot announce what the field is for.

Inaccessible
<div class="form-group">
  <span class="label">Email Address</span>
  <input type="email" name="email">
</div>
Accessible
<div class="form-group">
  <label for="email">Email Address</label>
  <input type="email" id="email" name="email">
</div>

Placeholder text used as the only label

A form field relies solely on placeholder text to describe the expected input. Placeholders disappear when the user starts typing, removing the label at the moment it is most needed for reference.

Inaccessible
<input type="text" placeholder="Full Name">
<input type="email" placeholder="Email Address">
<input type="tel" placeholder="Phone Number">
Accessible
<div class="form-group">
  <label for="name">Full Name</label>
  <input type="text" id="name" placeholder="e.g., Jane Smith">
</div>
<div class="form-group">
  <label for="email">Email Address</label>
  <input type="email" id="email" placeholder="e.g., jane@example.com">
</div>
<div class="form-group">
  <label for="phone">Phone Number</label>
  <input type="tel" id="phone" placeholder="e.g., (555) 123-4567">
</div>

Radio button group without a group label

A set of radio buttons has individual labels but no group label explaining the question or category they belong to. Screen reader users hear individual option labels without context.

Inaccessible
<div>
  <input type="radio" id="opt1" name="plan" value="basic">
  <label for="opt1">Basic</label>
  <input type="radio" id="opt2" name="plan" value="pro">
  <label for="opt2">Pro</label>
  <input type="radio" id="opt3" name="plan" value="enterprise">
  <label for="opt3">Enterprise</label>
</div>
Accessible
<fieldset>
  <legend>Select a pricing plan</legend>
  <input type="radio" id="opt1" name="plan" value="basic">
  <label for="opt1">Basic - $9/month</label>
  <input type="radio" id="opt2" name="plan" value="pro">
  <label for="opt2">Pro - $29/month</label>
  <input type="radio" id="opt3" name="plan" value="enterprise">
  <label for="opt3">Enterprise - $99/month</label>
</fieldset>

How to Test

  1. Click on every visible form label and verify the corresponding input receives focus (confirming the label is programmatically associated).
  2. Navigate all form fields with a screen reader and confirm each one announces a descriptive label that matches or includes the visible label text.
  3. Check that required fields are clearly identified both visually and programmatically (using aria-required='true' or the required attribute), and that the convention for indicating required status is explained.
  4. Verify that format instructions (date formats, password requirements, character limits) are provided before the input, not only after a failed submission.

CMS-Specific Guidance

This criterion commonly causes issues on these platforms:

Further Reading

Related WCAG Criteria