WCAG 3.3.2 Labels or Instructions

Success criterion 3.3.2 makes sure everyone knows what to enter into a form. People with cognitive disabilities, older users, screen reader users and anyone filling in a checkout on a small phone benefit from clear labels, visible required markers and short format hints. It is level A and appears in EN 301 549 as clause 9.3.3.2.

What the criterion requires

Labels or instructions must be provided when content requires user input. W3C notes that "requires" means accepts or expects input, so optional fields count too.

• A label is text (or a component with a text alternative) presented to all users to identify a control. It does not have to be an HTML <label> element, but it has to be visible to everyone — unlike an accessible name, which may be hidden.
• Instructions explain expected data or format, for example "Date of birth (DD.MM.YYYY)", which fields are required, or what a group of radio buttons is about.

The aim is useful cues without clutter: not every field needs a paragraph, but nobody should have to guess.

Typical failures on an online shop

• checkout fields that use only placeholder text, which disappears once the user starts typing;
• a phone or card field split into several boxes with no label for each part;
• required fields marked only with a red asterisk and no explanation of what the asterisk means;
• radio buttons for delivery options or checkboxes for consent with no group label;
• a quantity field, search box or newsletter field with an icon but no visible text;
• an unusual format (VAT ID, password rules) with no hint before the user makes a mistake.

How to check it

Automated: our checker runs form-field-multiple-labels, which flags fields with more than one label. The related rules for missing accessible names (such as label, select-name) are listed under 4.1.2. Whether a label is visible and understandable needs a person.

By hand: go through each form. For every field, check there is visible text that stays on screen while typing, that required fields are indicated in text, that groups of options have a heading or legend, and that special formats are explained before input.

How to fix it

• Give each field a visible <label for="…">; keep placeholders for examples only.
• Group radio buttons and checkboxes in <fieldset> with a <legend>.
• Mark required fields in the label ("Email (required)") or explain the asterisk at the top of the form.
• Add a short format hint and connect it with aria-describedby.

Related criteria

• 3.3.1 Error Identification — what happens when input is wrong.
• 4.1.2 Name, Role, Value — the programmatic name of each field.
• 1.3.5 Identify Input Purpose — autocomplete for personal data fields.

Frequently asked questions

Is placeholder text enough as a label?

It is risky. The placeholder disappears as soon as the user types, is often low contrast and is not always read by assistive technology. A visible label that stays on screen is the reliable solution.

Does 3.3.2 only apply to required fields?

No. W3C explains that "requires" here means accepts or expects input, so optional fields need labels or instructions too.

Do I need to mark required fields?

It is the expected way to meet 3.3.2 when some fields are required: W3C lists indicating required fields in the label or legend as a sufficient technique. Use text or an explained symbol, not colour alone.

What is the difference between 3.3.2 and 4.1.2?

3.3.2 is about labels and instructions that all users can see. 4.1.2 is about the accessible name that software reads. A field can have a hidden name and still lack a visible label.