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
<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.
- Element marked as decorative is not exposedA tool can check this
- Image accessible name is descriptiveA tool finds candidates, you decide
- Image button has non-empty accessible nameA tool can check this
- Image has non-empty accessible nameA tool can check this
- Link has non-empty accessible nameA tool can check this
- Object element rendering non-text content has non-empty accessible nameA tool can check this
- SVG element with explicit role has non-empty accessible nameA tool can check this
- Image not in the accessibility tree is decorativeA tool can check this
- ARIA attribute is defined in WAI-ARIAA tool can check this
- ARIA state or property has valid valueA tool can check this
- Element with role attribute has required states and propertiesA tool can check this
- Form field has non-empty accessible nameA tool can check this
- Headers attribute specified on a cell refers to cells in the same table elementA tool can check this
- Role attribute has valid valueA tool can check this
- ARIA global properties not used where prohibitedA tool can check this
- ARIA required context roleA tool can check this
- ARIA required owned elementsA tool can check this
- ARIA state or property is permittedA tool can check this
- Table header cell has assigned cellsA tool can check this
- Button has non-empty accessible nameA tool can check this
- Element with aria-hidden has no content in sequential focus navigationA tool can check this
- Element with presentational children has no focusable contentA tool can check this
- Menuitem has non-empty accessible nameA tool can check this
- Summary element has non-empty accessible nameA tool can check this
- Iframe element has non-empty accessible nameA tool can check this
- Iframe elements with identical accessible names have equivalent purposeA tool finds candidates, you decide
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.
- ARIA6sufficientName icon-only controls with aria-label
- ARIA9sufficientAssemble one label from several text pieces
- ARIA10sufficientName images and charts with aria-labelledby
- ARIA15sufficientLink complex images to longer descriptions
- C9sufficientPut decorative images in CSS backgrounds
- G68sufficientDescribe the purpose of live-only streams
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.