Requires labels or instructions wherever content asks for user input, including formats, required fields and grouped controls.
A box with no label gives no clue what to type. A date field that does not say which format it expects, or a required field that is not marked, sends people into errors that clear instructions would have prevented.
This criterion requires that labels or instructions are provided when content requires user input.
TRfieldset and legend, and each field also has its own label (H71, F82).People with cognitive, language and learning disabilities, who benefit most from clear labels and examples. Screen reader users, who hear the label when they reach the field. People with low vision who need to see the label and the instruction. Anyone filling in a form in an unfamiliar format.
The European Accessibility Act (Directive (EU) 2019/882) applies to in-scope products and services placed on the market after 28 June 2025. Recital 47 names four principles for websites and mobile applications: perceivable, operable, understandable and robust. Labels and instructions are part of "understandable".
The technical counterpart is the standard EN 301 549, which incorporates WCAG 3.3.2 by reference and turns it into separate clauses for each kind of ICT.
| Clause | Type of ICT | What it requires |
|---|---|---|
| 9.3.3.2 | Web pages | Web content must satisfy WCAG success criterion 3.3.2. |
| 10.3.3.2 | Non-web documents (PDF, Office files) | Documents must provide labels or instructions for form controls where the standard applies the criterion to them. |
| 11.3.3.2 | Non-web software (native mobile apps) | Software must provide labels or instructions when it requires user input. |
Whether and how the criterion applies to non-web documents is stated in clause 10 of the standard. Clause numbers follow the "9. + WCAG number" pattern of EN 301 549. In V3.2.1 the software clause is divided into further subclauses for open and closed functionality. Check the exact numbers in the standard when you cite them.
Standard version: EN 301 549 V4.1.1 (September 2026) is based on WCAG 2.2 and is the first version prepared specifically for the EAA. It has not yet been cited in the Official Journal of the European Union, so for now it is best treated as a voluntary technical route to the EAA's requirements. Once cited, it will give a presumption of conformity. The text of criterion 3.3.2 is the same in WCAG 2.1 and 2.2.
A note on EAA scope: Article 2(4) of the Directive excludes certain content from the requirements, for example office file formats published before 28 June 2025 and archives that are not updated after that date. Content you publish or change after that date is not covered by these exclusions.
Directive (EU) 2019/882, EUR-Lex, opens in a new tab
A control must have a label. Use label to connect them (H44).
<input type="text" name="city"><label for="city">City</label>
<input id="city" name="city">State the format, or give an example, before the user types.
<label for="dob">Date of birth</label>
<input id="dob"><label for="dob">Date of birth</label>
<input id="dob" aria-describedby="dob-hint">
<p id="dob-hint">Use the format DD/MM/YYYY, for example 31/03/1990.</p>Say that a field is required in text, and explain any symbol you use.
<label for="name">Name <span style="color:red">●</span></label><p>Fields marked with * are required.</p>
<label for="name">Name *</label>
<input id="name" required>Radio buttons and check boxes need a shared label as well as one for each option.
<p>Delivery method</p>
<input type="radio" name="d"> Courier
<input type="radio" name="d"> Pickup<fieldset>
<legend>Delivery method</legend>
<label><input type="radio" name="d"> Courier</label>
<label><input type="radio" name="d"> Pickup</label>
</fieldset>Formatting boxes visually to look like a phone number is not a label (F82). Label the group and each box.
(<input size="3">) <input size="3"> - <input size="4"><fieldset>
<legend>Phone number</legend>
<label>Area code <input size="3"></label>
<label>Prefix <input size="3"></label>
<label>Number <input size="4"></label>
</fieldset>A placeholder disappears as soon as the user types, so keep a visible label as well.
<input placeholder="Email address"><label for="email">Email address</label>
<input id="email" placeholder="[email protected]">In native forms, give every field a visible label, and put format hints and required markers in text. A label that disappears on input should be backed by a persistent one.
import SwiftUI
struct SignUpForm: View {
@State private var email = ""
var body: some View {
VStack(alignment: .leading) {
// A visible label, plus a hint about the expected format
Text("Email address *")
TextField("[email protected]", text: $email)
.textFieldStyle(.roundedBorder)
.accessibilityLabel("Email address")
.accessibilityHint("Required. For example [email protected]")
Text("Fields marked * are required.").font(.footnote)
}
}
}import androidx.compose.material3.OutlinedTextField
import androidx.compose.material3.Text
import androidx.compose.runtime.*
@Composable
fun SignUpField() {
var email by remember { mutableStateOf("") }
OutlinedTextField(
value = email,
onValueChange = { email = it },
// The label stays visible when the field has text
label = { Text("Email address *") },
// A hint about the expected format
supportingText = { Text("Required. For example [email protected]") }
)
}Corpowid has been recognized by Gartner, a leading global research and advisory firm, for our innovation and performance in digital accessibility. These badges reflect our commitment to creating inclusive, AI-powered web experiences.
