WCAG 3.3.2 Labels or Instructions

What it asks

A label names the field: "Email address", "Date of birth". Instructions say what else the person needs to know: that the field is required, that the date goes day first, that the password needs eight characters. This rule asks that one or both are there whenever the page wants something typed, chosen or uploaded. It is about making the ask clear in advance, so that fewer people make mistakes in the first place.

The label has to be there for everyone. A placeholder that disappears when typing starts is not a label: it is gone when the person most needs it, and many screen readers do not treat it as one. A label that only exists in the code, with nothing visible, helps a screen reader user and nobody else. The visible text and the programmatic label should be the same thing.

The criterion does not require every field to carry long instructions. A field labelled "Town" needs nothing more. A field with a required format, a limit or a rule that the person could not guess does. It is Level A, and it is related to 3.3.1 Error Identification, which covers what happens after the mistake this criterion tries to prevent.

Its official name is success criterion 3.3.2 Labels or Instructions, at Level A. It was added in WCAG 2.2, under guideline 3.3 Input Assistance and the principle Understandable. The W3C’s normative text says, in part:

“Labels or instructions are provided when content requires user input.”

From WCAG 2.2, W3C. Full explanation: Understanding 3.3.2 Labels or Instructions.

Who it helps

Screen reader users, who hear the label when they reach the field and nothing at all when there is no label. People with cognitive disabilities and memory difficulties, who need to be told what is wanted and in what form rather than guessing.

People with motor disabilities, for whom every failed submission is an expensive retry. And everyone filling in a form on a phone, where a placeholder vanishes the moment they start to type.

What passes and what fails

These pass

• A visible <label> for every field, connected with for and id.
• "Date of birth (DD/MM/YYYY)" as the label of a date field, or the format given in text linked with aria-describedby.
• Required fields marked "required" in the label, or an asterisk with a line at the top of the form explaining that an asterisk means required.
• Password rules stated above the field before anyone types.
• A group of radio buttons with a visible question as its group label.

These fail

• A placeholder as the only label, which disappears when the person starts to type.
• Required fields marked only with a red asterisk and nothing on the page saying what the asterisk means.
• Password rules revealed only in the error message after a failed attempt.
• A date field with no indication of the format it expects.
• A search field with no label and a magnifying glass button with no name.

Whether every required field must be marked as required is not settled by the W3C’s own text, which does not say so in as many words. Dreven’s reviewers apply a stated policy here: a form that marks none of its required fields is reported as not meeting the criterion, and the report says this is a policy rather than quoting WCAG for it.

How to test it by hand

1. Open each form and look at every field, including search boxes and fields that appear after a choice.
2. Check that each has visible text naming it. Click the text: if the field gains focus, the label is connected in the code. If not, inspect the field in the developer tools and look for a <label>, aria-label or aria-labelledby.
3. Check that a placeholder is not doing the label’s job on its own.
4. For each field with a required status, a format, a limit or a rule, check that the page says so before the person types, and that the text is linked to the field or sits where it will be read before it.
5. Write down every field with no label, a placeholder-only label, or a rule revealed only on error.

What automated testing can decide

What a machine can decide

Whether a field has an accessible name is mechanical, and a field with none is a clear failure. A tool can also tell whether the name comes from a visible label or only from a placeholder or a hidden attribute, and can read the field’s declared rules: required, pattern, minimum and maximum, type.

What it cannot

Whether the instructions are enough is a judgement. A tool can see that a field has a pattern and that there is text near it; it cannot be certain that the text explains the pattern in a way a person can act on. "Phone number (UK)" may be enough for one field and not for another. That half of the criterion needs a person, and the two halves should be reported as separate lines.

How Dreven handles it

Dreven finds the form fields on your pages and shows you each one, with its label, any instructions around it and a picture of it in place.

A reviewer decides whether each field is labelled and whether the instructions are enough, and the report records those as separate results, so a form can be clear on one and short on the other.

No automated check makes a site conform. In Dreven, a person reviews the results and signs the report.

Related criteria

• 3.3.1 Error Identification (Level A). When the person still makes a mistake, the error must be identified and described.
• 3.3.3 Error Suggestion (Level AA). When the site knows the fix, it says so.
• 1.3.1 Info and Relationships (Level A). A visible label must also be connected to its field in the code.
• 2.4.6 Headings and Labels (Level AA). Labels must describe the field, as well as exist.
• 4.1.2 Name, Role, Value (Level A). A field needs an accessible name for assistive software.

Questions people ask

All WCAG 2.2 criteria, in plain words