3.3.2 Labels or Instructions
- Level A
- Understandable
- Since WCAG 2.0
Summary
When a form asks for something, the user has to be able to tell what it is asking for, before, during, and after they type. This criterion protects people with cognitive and memory impairments who cannot hold an unlabelled field's purpose in mind, people with low vision who zoom in and lose surrounding context, and screen magnifier users who may only ever see one field at a time. It is a Level A requirement, part of WCAG since 2.0, and under the European standard it applies unchanged to web content and software.
The auditor's mental model: this criterion is about the presence and sufficiency of visible labelling, nothing more. Does every input have a visible label or instruction that stays available while the user works? Are format requirements (date formats, password rules) and required-field markers presented before the user can get them wrong? Whether the label is programmatically associated, well worded, or echoed in the accessible name are separate criteria; here you grade only whether adequate visible labelling exists at all.
Official wording
Labels or instructions are provided when content requires user input.
EN 301 549 mapping
- Web pages
- Clause 9.3.3.2
- Software and native apps
- Clause 11.3.3.2
Clauses 9.3.3.2 (web) and 11.3.3.2 (software) apply this criterion unchanged, so the same requirement binds web pages and native app user interfaces.
Clause references are to EN 301 549 V3.2.1 (2021-03), the harmonised European standard. Descriptions are our own summary, not the text of the standard.
In practice
Web
Sweep every form and every standalone input (search boxes, newsletter sign-ups, quantity steppers, filters). For each field ask three questions: is there a visible label or instruction, does it persist while the user types, and does it tell the user enough to enter valid data on the first attempt?
The canonical fail is the placeholder-only field. A placeholder attribute looks like a label until the user starts typing, at which point it vanishes: the person filling in the form loses the one piece of text identifying the field exactly when they need to check it. Grade placeholder-only fields as fails under this criterion. Floating label patterns, where the placeholder text animates up into a persistent small label on focus, pass, because a visible label remains for the life of the interaction.
Then check instructions. If a field demands a specific format (date as day/month/year, phone with country code, a password with length and character rules), that requirement must be visible before submission, not revealed only by the error message after the user fails. Check that required fields are indicated: an asterisk with a visible key, the word "required", or an equivalent visible convention. A form where every field is required can say so once at the top. Use browser devtools only to confirm what is genuinely visible in the rendered page; this criterion is graded with your eyes, not the accessibility tree.
iOS
The same requirement applies to native apps under the European standard, and placeholder-only text fields are extremely common in iOS apps: a UITextField or SwiftUI TextField with placeholder text and no separate label looks clean in a design review and fails here. Type a character into every field and watch what happens: if the only text identifying the field disappears, that is the fail. Floating label implementations pass, as does a persistent caption above or beside the field.
Walk each form screen on device. Check that password rules, date formats, and required markers appear on the screen before the user submits, not only in a post-failure alert. Where input is gesture-driven (a signature pad, a re-order-by-drag list, a slider with no scale, a pull-down to reveal a hidden field), look for visible instructions telling the user what gesture is expected; an unexplained blank canvas that requires a drawn signature is an instructions failure. Accessibility Inspector can tell you what a field's accessible label is, but remember that a perfect accessible label with no visible text is still a fail under this criterion: VoiceOver users are covered, sighted users with cognitive impairments are not.
Android
Identical sweep on Android. The classic offender is an EditText with only android:hint, or a Compose TextField with only placeholder content: the hint disappears on input. The standard Material text field component uses a floating label by default, so apps built on it usually pass; apps that suppress the label or use a bare EditText styled to look minimal are where the fails cluster. Type into every field and confirm identifying text persists.
Check the same instruction points: format requirements and password rules visible up front, required fields marked, units stated where a bare number would be ambiguous (weight in kg or lb). For gesture-driven inputs (swipe-to-set controls, drawing fields, drag-to-rank lists), confirm the screen visibly explains the expected interaction. Layout Inspector is useful for confirming whether a text element you can see is a real persistent label or a hint that will vanish, but as on iOS, the grading evidence is what a sighted user sees on the running app.
Pass and fail examples
Passes:
- Every field in a checkout form has a visible text label above it that remains while the user types.
- A date field is labelled "Date of birth" with the visible hint "DD/MM/YYYY" beside it.
- A password field lists its rules ("at least 12 characters, one number") below the input before the user types anything.
- A floating label text field in a native app: the placeholder animates into a persistent small label on focus, so identifying text is always visible.
- A form states "All fields are required" once at the top, and none of the individual fields carries a marker.
Fails:
- A login form where "Email" and "Password" exist only as placeholder text that disappears on input.
- A phone number field that rejects entries without a country code but gives no visible indication that one is needed until the error appears.
- A required field with no visible required indication, where optional fields sit alongside it unmarked.
- A signature capture area presented as a blank box with no visible instruction that the user must draw their signature.
- An app text field whose only identification is the accessible label read by the screen reader, with no visible text for sighted users.
Not a fail under this criterion:
- A visible label that is not programmatically associated with its input: the label is present, so this criterion passes; the missing association is a 1.3.1 finding.
- A visible label that is vague or unhelpful ("Field 1"): presence is satisfied; descriptiveness belongs to 2.4.6.
- An error message that appears after submission without identifying the field in error: that is a 3.3.1 finding; this criterion is about what the user sees before they fail.
- A visible label that the control's accessible name does not contain: file that under SC 2.5.3 Label in Name.
Commonly confused with
- Info and Relationships, SC 1.3.1. The cleanest split in a form audit: 3.3.2 asks whether a visible label exists, 1.3.1 asks whether it is programmatically associated with the control. A visible but unassociated label passes here and fails there; a properly associated label that vanishes on typing fails here. One finding, one criterion.
- Headings and Labels, SC 2.4.6. Presence versus quality. If a label exists but describes the field poorly, that is a 2.4.6 descriptiveness finding, not a 3.3.2 one. If no adequate visible label exists at all, it is 3.3.2.
- Error Identification, SC 3.3.1. Instructions prevent, errors respond. Format rules and required markers shown before input are 3.3.2; how the page identifies and describes an error after a failed submission is 3.3.1. A form can fail both: no format hint up front, then a vague error afterwards.
- SC 2.5.3 Label in Name. Whether the accessible name contains the visible label text is a 2.5.3 question for speech input users. 3.3.2 does not look at the accessible name at all; a field can pass 3.3.2 with a perfect visible label and still fail 2.5.3.
- Placeholder disputes. A placeholder can serve as a candidate visible label for 2.5.3 purposes when nothing else identifies the field, but that does not rescue it here: because it disappears during input, a placeholder-only field still fails 3.3.2.
How AUDITSU tests this
AUDITSU's audit walkthrough covers labels and instructions on every screen that accepts input. For each form screen the walkthrough asks you to confirm that every field has a visible, persistent label, that format requirements and required-field markers are shown before submission, and that gesture-driven inputs carry visible instructions; typing into each field to watch for vanishing placeholders is part of the procedure. Each question records a pass, fail, or not applicable result per screen with evidence attached, so a placeholder-only login field lands in your report tied to the exact screen, separated cleanly from any related 1.3.1 or 3.3.1 findings on the same form.
Because the European standard applies this criterion unchanged to both web content and software, the walkthrough runs the same checks across website and native app audits.
For the full guided workflow, see the audit platform.