Level A

33.1% of form inputs on home pages lack a proper accessible label

3.3.2 Labels or Instructions

In Plain Language

[3.3.2 Labels or Instructions](https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html) is a Level A criterion that fires whenever content requires user input: every form control must be accompanied by a label or instruction that tells the user what to enter[1]. The label or instruction has to be presented to the user -- a field whose only cue is a placeholder that vanishes the moment the user focuses it does not satisfy the criterion.

When a field has a format constraint -- date, phone, postal code, password rules -- the instruction has to name the format up front ("Format: MM/DD/YYYY", "10 digits", "at least 8 characters"). Making the user submit the form to learn the format is a 3.3.2 failure, not a UX preference.

Why It Matters

  • 3.3.2 is distinct from 1.3.1 and 4.1.2. 1.3.1 asks whether the label/input relationship is exposed programmatically (a <label for> pointing at an id, or aria-labelledby). 4.1.2 asks whether the control has an accessible name at all (aria-label alone is enough). 3.3.2 asks whether a human-visible label or instruction is presented to the user -- a control can pass 4.1.2 via aria-label yet fail 3.3.2 because sighted users get nothing to read[1].
  • Screen-reader users depend on the accessible name computed from the label to distinguish one field from another. Without a label element or equivalent, the computed name falls back to the placeholder (inconsistent across browsers and assistive tech) or to nothing at all, and the field is announced as "edit text".
  • Placeholder text fails as a label substitute for four independent reasons: it disappears the instant the user types, so anyone who pauses loses the cue; it is styled by default with low contrast that trips 1.4.3 for low-vision users; it is not reliably exposed to the accessibility API as the accessible name; and auto-fill can overwrite it without the user realising a field existed.
  • Users with cognitive and learning disabilities lose orientation when a label disappears on focus -- the field becomes an unlabeled box, and recovering the prompt requires blurring and re-focusing. A persistent visible label removes the memory load entirely.
  • WebAIM Million 2026 found that 33.1% of form inputs on the analysed home pages were not properly labelled through <label>, aria-label, aria-labelledby, or title[2] -- a third of the form surface of the top million sites ships without the basic association 3.3.2 requires.

Examples

Do: Provide a visible label for every input field

✔ Each input has a visible label that describes what to enter

<label for="name">Full name</label>
<input id="name" type="text">

<label for="email">Email address</label>
<input id="email" type="email">
Don't: Use placeholder text as the only label

✘ Placeholder disappears on focus -- no persistent label, no programmatic association

<!-- FAILS: no label element, placeholder is not a label -->
<input type="text" placeholder="Full name">
<input type="email" placeholder="Email address">
<!-- Placeholder vanishes on focus, no screen reader label -->
Do: Include format instructions for fields with specific requirements

Format: MM/DD/YYYY

10 digits, e.g. 202-555-0100

✔ Labels plus format hints linked via aria-describedby

<label for="dob">Date of birth</label>
<input id="dob" type="text"
  aria-describedby="dob-hint">
<p id="dob-hint" class="hint">
  Format: MM/DD/YYYY
</p>

<label for="phone">Phone number</label>
<input id="phone" type="tel"
  aria-describedby="phone-hint">
<p id="phone-hint" class="hint">
  10 digits, e.g. 202-555-0100
</p>
Don't: Omit instructions for fields with required formats

✘ No format hints -- user must guess the expected date and phone format

<!-- FAILS: label exists but no format instruction -->
<label for="dob">Date of birth</label>
<input id="dob" type="text">
<!-- MM/DD/YYYY? DD-MM-YYYY? User has to guess. -->

How to Fix It

  1. Give every <input>, <select>, and <textarea> a <label for="id">. The for/id association is the most reliable pattern in HTML: it survives DOM reordering, clicking the label focuses the input, and the label text becomes the accessible name with no ARIA required. Wrapping the input inside the <label> element is an equivalent pattern when an explicit id is inconvenient.
  2. Use aria-label only when the visible label is not text. The canonical case is an icon-only search field where the magnifying glass is the visible cue; add aria-label="Search" (or aria-labelledby pointing at an off-screen string) so the accessible name exists. Do not use aria-label as a replacement for a visible label on a normal text field -- sighted users see nothing, which is exactly the 3.3.2 failure the criterion is written to catch[1].
  3. Put format hints in the DOM and wire them to the input with aria-describedby. A visible "Format: MM/DD/YYYY" paragraph adjacent to the field, referenced by aria-describedby, is announced by screen readers after the label and remains visible for sighted users. placeholder is not a substitute -- it disappears on input and is not a reliable accessible description for assistive technology.
  4. Mark required fields with a visible cue and required. The visible cue (asterisk plus a "required fields marked with *" note, or the word "required" in the label) satisfies 3.3.2. The required attribute (or aria-required="true" on custom widgets) exposes the constraint to assistive technology so the requirement is announced, not just seen.
  5. Group related controls with <fieldset> and <legend>. A set of radio buttons, a split date entry, or a billing-address block needs the shared context that individual labels cannot carry. The <legend> is prepended to each control's accessible name during announcement, which is how a screen-reader user learns that "Monday" belongs to "Preferred contact day" and not to "Delivery day".

References

  1. [1] W3C (2023). Understanding Success Criterion 3.3.2: Labels or Instructions. W3C, Accessed 2026-04-07. https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html ↩ ↩ ↩
  2. [2] WebAIM (2026). The WebAIM Million: An accessibility analysis of the top 1,000,000 home pages. WebAIM, Accessed 2026-04-07. https://webaim.org/projects/million/ ↩