WCAG 3.3.2 Labels or Instructions — Testing Guide

WCAG 3.3.2 Labels or Instructions (Level A) requires labels or instructions when content requires user input. Every form field, every interactive control that takes input, must clearly tell the user w

WCAG 3.3.2 Labels or Instructions (Level A) requires labels or instructions when content requires user input. Every form field, every interactive control that takes input, must clearly tell the user what is expected. Without labels, users — particularly those using screen readers — cannot operate the control.

What it requires

Each input control has:

1. A visible label OR alternative (e.g., icon with adjacent label, legend grouping related fields)
2. Programmatic association between the label and the control (so screen readers announce it)
3. Additional instructions where format is non-obvious (date format, password requirements, required fields)

Common violations

1. Placeholder as label

<input type="email" placeholder="Email">

Placeholder disappears on focus. User forgets what field is. Also fails contrast often.

Fix:

<label for="email">Email</label>
<input id="email" type="email" placeholder="you@example.com">

2. No visible label

Icon-only button with no accessible label.

Fix: aria-label, visible text nearby, or aria-labelledby.

3. Label not associated

Text near input but not in with for=. Visual association only.

Fix: Use or wrap around .

4. Format not disclosed

Date field. User types "12/01/24". Submit fails because expected "2024-12-01". No instructions.

Fix: "MM/DD/YYYY" format hint adjacent. Or use input type="date" (date picker).

5. Required field not indicated

User fills form, submits, 3 errors appear. Should have been told upfront which were required.

Fix: Visual marker (asterisk with legend), programmatic marker (required attribute or aria-required).

6. Password rules hidden

"Password must be 12+ chars, uppercase, number, symbol" only shown after submit error.

Fix: Rules visible adjacent to input, or on focus.

Fix patterns

Semantic labels

<label for="phone">Phone number</label>
<input id="phone" type="tel" inputmode="numeric"
       aria-describedby="phone-help" required>
<small id="phone-help">Include country code, e.g., +1 555 555 5555</small>

Screen reader announces: "Phone number, required, edit, phone number type, hint: Include country code..."

Grouped controls (fieldset + legend)

<fieldset>
  <legend>Shipping address</legend>
  <label>Street: <input name="street"></label>
  <label>City: <input name="city"></label>
  ...
</fieldset>

Related fields have context.

Error messages with field association

<label for="email">Email</label>
<input id="email" type="email" aria-invalid="true" aria-describedby="email-error">
<span id="email-error" role="alert">Please enter a valid email.</span>

Screen reader announces error with field.

Testing

Automated

• axe-core checks label association on every input
• Lighthouse
• Accessibility scanner (mobile)

Manual

• Screen reader tour: each input should announce name + instructions
• Remove values, refocus — do labels remain visible?
• Ambiguous instructions ("fill this in correctly") should become specific

Visual without screen reader

• Placeholder text should not be load-bearing
• Labels visible at all times
• Format hints adjacent

Mobile specifics

Android

<EditText
  android:hint="Email"
  android:inputType="textEmailAddress"
  android:labelFor="@+id/email_label" />
<!-- labelFor is less common; use android:contentDescription or explicit label -->

Compose:

OutlinedTextField(
    value = email, onValueChange = { email = it },
    label = { Text("Email") },
    supportingText = { Text("We'll never share it.") },
    isError = emailInvalid,
    keyboardOptions = KeyboardOptions(keyboardType = KeyboardType.Email)
)

iOS

SwiftUI:

TextField("Email", text: $email)
    .textContentType(.emailAddress)
    .keyboardType(.emailAddress)
    .accessibilityLabel("Email address")
    .accessibilityHint("We'll never share it")

Additional requirements related to 3.3.2

• WCAG 1.3.1 (Info and Relationships): label programmatic association
• WCAG 3.3.1 (Error Identification): errors linked to specific fields
• WCAG 3.3.3 (Error Suggestion): errors suggest fixes
• WCAG 3.3.4 (Error Prevention): financial / legal / data actions allow reversal / confirmation

How SUSA tests 3.3.2

SUSA's accessibility_user persona checks every input field for:

• Missing label (critical)
• Label without programmatic association (high)
• Required field not indicated (medium)
• Format not disclosed (medium)

For each finding, reports selector / element ID, the issue, and suggested fix. Runs on every discovered form screen.

susatest-agent test myapp.apk --persona accessibility_user --wcag-level A

Common mistakes

1. Adding aria-label AND with different text — confuses assistive tech
2. Label hidden visually with display: none — screen reader does not read it
3. Tooltip as instruction — only on hover, inaccessible to keyboard / touch
4. Instructions in a separate help modal — user must leave form to read

Labels are basic. Get them right; everything downstream becomes easier.