Skip to main content
WCAGrules
Quick navigation

Attach a real label to every form field

Every input needs a label element wired to it, either a label whose for attribute matches the field's id or a label wrapped around the field itself. Sitting next to it on screen counts for nothing, because the connection has to exist in the code. W3C lists H44 as sufficient for four criteria, 1.1.1 Non-text Content, 1.3.1 Info and Relationships, 3.3.2 Labels or Instructions and 4.1.2 Name, Role, Value. One of them behaves differently from the rest, in a way that decides real designs. A visually hidden label still satisfies the naming rules, since software can read it perfectly well. It does not satisfy 3.3.2 Labels or Instructions, where W3C says plainly that the label element must be visible. A search box whose label is hidden from sight passes one rule and fails the other. Placeholder text is not a label either, and that comes from how a name gets computed rather than from this technique. There is a small positioning convention inside the test as well. The label goes before a text field and after a checkbox or a radio button.

How we find it in an audit

The one-second test is clicking the label text. If focus jumps into the field they are connected, and if nothing happens they are two things that merely sit near each other. On audited forms we also read what the accessibility tree names every control, because that is the name a screen reader will speak. An unattached label leaves the field announced as edit text, with no name at all. Then we check the visible half separately, since a hidden label passes the naming rules and still fails 3.3.2.

How affected users experience it

A labeled field announces its job on arrival. Email address, edit text. An unlabeled one announces edit text and stops, which leaves the listener a blank to fill from guesswork. Guessing is survivable on a newsletter signup. On a checkout where billing and delivery fields alternate, it means card details typed into the wrong box, and most people do not try a second time. A wired label helps somebody else as well. It turns the whole label text into a click target for the field, which matters to anyone whose hand is not steady on a mouse.

Passes vs. fails

Passes: a label that stays put. Fails: placeholder-only fields.

Passes

<label for="email">Email address</label>
<input id="email" name="email" type="email">

Fails

<p>Email</p>
<input type="email" placeholder="Email">

How this gets tested

The W3C publishes test rules that define what a checker looks for here.

Other ways to satisfy this rule

39 guides on this site are filed under 1.1.1 Non-text Content. W3C lists this one as sufficient for that rule on its own. Implement it correctly, in a way your readers' software actually supports, and the rule is met.

This guide is our interpretation of W3C technique H44: Using label elements to associate text labels with form controls. W3C publishes its techniques as guidance rather than as the standard, and says so on every one of them. The success criterion is what conformance is measured against, and a technique is one documented way to meet it.

Go somewhere useful

Find tools, resources and your workspace.

29 destinations