Success Criteria

WCAG 3.3.2 Labels or Instructions

Success Criterion 3.3.2 requires that labels or instructions are provided when content requires user input. It's a Level A criterion under Guideline 3.3 (Input Assistance) — closely related to, but distinct from, WCAG 4.1.2's requirement that a label be programmatically associated with its field.

The distinction from 4.1.2

3.3.2 is about whether guidance exists at all — every field a user needs to fill in should have a label or instruction telling them what's expected (a name, an email address, a date in a specific format). 4.1.2 (Name, Role, Value) is about whether that guidance is correctly wired up so assistive technology can access it. A field can satisfy one and fail the other: visible text sitting near an input, with no for/id association, arguably gives a sighted user enough of a label to satisfy 3.3.2's intent, while still failing 4.1.2 because a screen reader gets no programmatic connection to it at all. In practice, both criteria point to the same fix, which is why Missing Form Labels covers the complete solution for both together.

Instructions beyond just labels

This criterion covers more than the basic "what is this field" question — it extends to format expectations and constraints the user needs to know before submitting, not just after getting a validation error:

• A password field with specific complexity requirements should state them upfront, not only reveal them after a failed submission
• A date field expecting a specific format (MM/DD/YYYY vs DD/MM/YYYY) should say so
• A field with a character limit is more usable when that limit is stated, not just enforced silently

Placeholder text still doesn't count

As with Missing Form Labels, placeholder text alone doesn't reliably satisfy this criterion either — it disappears the moment a user starts typing, and reappears empty if they clear the field, meaning any instruction that lived only in the placeholder vanishes exactly when the user might need to double-check it.

The required attribute isn't a substitute for saying so

Marking a field required in HTML changes browser validation behavior, but a required field should also communicate that requirement visually and in its accessible name or description (a * alone, with no explanation of what it means, is a common half-measure) — otherwise a user only discovers a field was mandatory after an error, which is the exact failure this criterion is meant to prevent.

Common questions

What is WCAG 3.3.2?

A Level A criterion requiring labels or instructions when content requires user input, so users know what each field is for and any format needed.

Is placeholder text a valid label?

No — placeholders disappear on input and often fail contrast; they don't reliably satisfy 3.3.2. Use a persistent label element.

What about required formats?

If a field needs a specific format (like a date or phone pattern), the label or instructions should state it up front.