The label element
Jointly authored by the Accessibility Task Force
An easy and effective way of improving a form’s accessibility is to use the label
element. Very few forms (or the tools that create them) seem to use the label
, which is really a shame – it’s flexible, functional, fun — and the best semantics for the job.
There are two main accessibility reasons for marking up the text for a form control with a label
:
- It allows the text description (for instance “Username”) to be announced to screen reader users as a prompt for each form control, so that there’s no ambiguity as to what the form control is for
- It increases the target area for people with mobility impairments, who might be using a mouse (or similar pointing device) but do not have fine motor control. The
label
element becomes clickable, in addition to the form control itself, which is often a tiny target to hit, such as a checkbox or a radio button
So the label
element allows a prompt to be associated with the form control to which it refers. The two main implementations of label
are implicit and explicit.
An implicit label
is simply wrapped around the form control:
<label>Username <input type="text" name="username" /></label>
An explicit label
creates an association using the label
element’s for
attribute, which refers to the id
of the associated form control:
<label for="username">Username</label>
<input type="text" name="username" id="username" />
It’s worth noting that both WCAG 1.0 checkpoint 12.4 and the current draft of WCAG 2.0 checkpoint 4.2.4 require label
elements to use this type of explicit association, and this is because support for implicit association is still patchy among user-agents.
A third method for using label
is effectively a mixture of the previous two: an implicit label
which also features the explicit for
attribute:
<label for="username">
<span>Username</span>
<input type="text" name="username" id="username" />
</label>
This belt and braces
approach is extremely robust, because it allows the label (and further neutral elements inside it) to be used as structural elements for styling the form, while remaining mindful of accessibility needs.
When labels are marked up this way, screen readers announce the associated prompt for the current form control (for example username; edit box
), so users know exactly what type of input or selection is required from them. In the absence of a label
element, screen readers have to employ common heuristics to guess the associated form control, based on the presence of text at a specific position around the form control – often with disastrous results.
Another benefit for mouse users is that clicking on a label
places focus on the associated form control. This is particularly useful for small controls like checkboxes and radio buttons, because it increases the target area, making it easier for people with motor problems to select the control.
Conclusion
The label
element allows prompts to be explicitly associated with the form control. This is beneficial to people using assistive technology, which relays the associated prompt for the form control to avoid any ambiguity, and also for people with motor problems, as it increases the “clickable” target area for the form control.
The Web Standards Project is a grassroots coalition fighting for standards which ensure simple, affordable access to web technologies for all.