Understandable · Level A · 3.3.2
Labels or Instructions
Every form field that expects input needs a label or instruction telling the user what to enter — real text, not just visual formatting or placement that happens to imply it. This is about that label or instruction existing at all; whether it's correctly, programmatically tied to the field is a separate concern.
- Cognitive
How to recognize it
Look for fields where the only clue about what to type is visual: three boxes with a parenthesis and a dash between them implying 'phone number,' with no label text anywhere. A field with only a placeholder and no persistent label — the placeholder disappears the moment someone starts typing, and isn't treated as a real label by all assistive technology anyway. A password field or date field whose format requirements (length, allowed characters, MM/DD/YYYY vs DD/MM/YYYY) are shown only as a faint visual hint, easy to miss, with the actual rule discovered only after getting it wrong and hitting an error. That last point is the clearest way to tell this apart from 3.3.1: 3.3.1 is about what happens after a wrong answer is submitted, this criterion is about whether the person had enough information to answer correctly in the first place. It's also distinct from 1.3.1: a field with a technically perfect <label for> pointing at it can still fail this criterion if the label text itself is missing or unhelpful — 1.3.1 is the markup mechanism, this is about the content actually being there.
How to fix it
Give every field a real text label, not a placeholder standing in alone. Where a specific format or constraint is required, spell it out as an instruction near the field — 'Format: MM/DD/YYYY,' 'At least 8 characters, including one number' — instead of leaving it to be inferred from a hint style or discovered only on error. This criterion doesn't technically require the label be programmatically associated with the input at all, just that it exists as real text somewhere a user can find before submitting — but doing that together with 1.3.1's <label for> is obviously the actual goal; either one without the other is still a partial failure of something.
Example
Avoid
<input type="tel"> ( <input type="tel" maxlength="3"> ) <input type="tel" maxlength="4">
<!-- format implied by grouping and punctuation, no label text --><input type="password" placeholder="Password">
<!-- requirements only appear after a failed attempt --><label for="dob">Date of birth</label>
<input id="dob" type="date">
<!-- no format hint; user has to guess MM/DD/YYYY vs DD/MM/YYYY -->Prefer
<label for="phone">Phone number</label>
<input id="phone" type="tel" placeholder="(555) 555-5555"><label for="pw">Password</label>
<input id="pw" type="password" aria-describedby="pw-hint">
<p id="pw-hint">At least 8 characters, including one number.</p><label for="dob">Date of birth (MM/DD/YYYY)</label>
<input id="dob" type="date">