3.3.2 Labels or Instructions

WCAG 2.2 · 3.3.2 A Understandable

What it requires

When content requires user input, labels or instructions must be provided so people know what is expected of them. Every form control needs a clear, visible label that describes its purpose, and any additional constraints — required fields, expected formats (such as a date pattern), or example values — must be conveyed in text rather than implied by placeholder colour, position, or shape alone. The criterion does not require a specific technique; it requires that the information needed to complete an input successfully is actually present and programmatically associated where relevant.

  • Screen reader users — an unlabelled field is announced only by its type (“edit text”), leaving no clue what to enter.
  • People with cognitive and learning disabilities — missing format hints or instructions make errors far more likely and harder to recover from.
  • Low-vision users — placeholder-only labels vanish on focus or fail contrast, removing the only cue to a field’s purpose.
  • Voice-input users — a visible label gives them a name to speak when targeting the control.

How to detect it

Checks for Labels or Instructions
Check What to look for
Manual review Every input, select, and textarea has a visible, persistent label that describes its purpose; required fields and format expectations are stated in text.
Keyboard / screen reader Tab to each control: the accessible name announced matches the visible label, and instructions are read out (not skipped).
Placeholder test Focus a field and type — if the only label was a placeholder, it disappears and the purpose is lost. That is a failure.
Zoom (200%) Labels and instructions stay visible and associated with their control at high zoom and reflow.
Automated tools axe and similar flag missing programmatic labels, but cannot judge whether an instruction is adequate — manual review is required.

How to fix it

  1. Give every control a real <label> tied to it via for/id.
  2. Keep the label visible and persistent — do not rely on a placeholder as the label.
  3. State requirements in text: mark required fields and describe expected formats.
  4. Associate extra hints programmatically with aria-describedby.
  5. Re-test with a screen reader to confirm the name and instructions are announced.
<label for="dob">Date of birth (required)</label>
<input id="dob" name="dob" type="text"
       inputmode="numeric"
       aria-describedby="dob-hint" required>
<p id="dob-hint">Format: DD/MM/YYYY, e.g. 31/12/1990</p>

Copy-paste tests

Automated coverage

The axe-core rule form-field-multiple-labels flags failures of this criterion. Run it via the axe DevTools browser extension or axe-core in CI. Automated tools only catch some failures, so manual review is still required.

Run this in the browser console

check-labels-3-3-2.js 
// Read-only: lists form controls lacking a visible label/instruction.
const suspects = [...document.querySelectorAll('input:not([type=hidden]), select, textarea')]
  .filter(el => {
    const id = el.id;
    const hasLabel = id && document.querySelector(`label[for="${id}"]`);
    const wrapped = el.closest('label');
    const aria = el.getAttribute('aria-label') || el.getAttribute('aria-labelledby');
    return !hasLabel && !wrapped && !aria;
  });
suspects.forEach(el => el.style.outline = '2px solid red');
console.table(suspects.map(el => ({ tag: el.tagName, type: el.type, name: el.name, id: el.id })));
console.log('Review these controls for a label or instruction:', suspects);

What to check manually: confirm each label actually describes its field (not just present but meaningful), and that required formats or constraints (e.g. date format, password rules) are stated before the user submits.