If you’re evaluating your website with an automated accessibility tool, you might see an error that references “missing input labels" or “missing form labels.”
In most cases, this occurs when form fields, checkboxes, radio buttons, or other interactive elements have no HTML label that describes their functionality. Since this can make your website unusable for people who use assistive technology, you’ll need to address the error quickly.
Fortunately, the underlying problem is easy to fix. Here’s what you’ll need to know.
How do HTML input labels improve accessibility?
The HTML <label> element is both visual and programmatically determinable. It appears on screen, so it’s readable for visual users, but it’s also announced by screen readers (software that converts text to audio or braille) and other assistive technologies.
Input labels are intended to describe the purpose of a data entry field. Screen readers can’t determine the purpose of an input field without help. If labels aren’t present, the software will only read out the type of field.
Your content might have missing input labels for several reasons. You might provide instructions via text outside of the <label> element, or you might use an image (such as a shopping cart logo) as a stand-in for text. This can lead to frustrating experiences for users.
The user might hear “edit,” “document, edit, blank,” “checkbox,” or some other combination of words, depending on which screen reader they use — and whether you’ve used appropriate markup — but they won’t receive any indication of the input field’s requirements.
Needless to say, this can be a costly mistake. If your eCommerce checkout has missing labels, for instance, you’re locking out (and most likely, annoying) your customers.
Related: How to Fix: "Buttons Do Not Have Accessible Names"
WCAG and Missing Input Labels
The Web Content Accessibility Guidelines (WCAG) are the international consensus standards for accessibility. Unsurprisingly, missing and incorrect labels are covered by WCAG.
Three success criteria are especially important here:
- WCAG 2.1 Success Criterion 3.3.2, “Labels or Instructions,” requires websites to provide labels or instructions when content requires user input.
- Under WCAG SC 1.3.1, “Info and Relationships,” labels must also have correct markup to identify them programmatically.
- WCAG 2.1 SC 4.1.2, “Name, Role, Value" requires that names and roles can be programmatically determined.
To follow these guidelines, ask two simple questions when writing your markup: Can assistive technologies interpret each input field, and can users understand how to operate the website?
An Example of the HTML <Label> Element
Here’s an example of the input label element for a checkbox input field that asks users whether they like dogs. This is considered an explicit use of the <label> element:
<div class="preference">
<label for="dogs">Do you like dogs?</label>
<input type="checkbox" name="dogs" id="dogs">
</div>
This markup has an accurate input label (“Do you like dogs?”), along with markup establishing the name of the element (“dogs") and associating the name with the label.
Implicit HTML Input Labels
Another way to use the <label> element is implicitly, which eliminates the for attribute by nesting the <input> within the <label>. This isn’t ideal for accessibility, because different screen readers may not handle implicit associations the same way.
Here’s an example of an implicit HTML label:
<label>Do you like dogs?
<input type="checkbox" name="dogs">
</label>
Wherever possible, use an explicit label with a for attribute. Remember that each <label> element can only be associated with a single form control, and finally, ensure that the accessible name matches the label.
To understand why this last point is important, read: How Accessible Names Can Help (Or Frustrate) Your Users.
Adding HTML input labels provides a more consistent experience for users
So, what happens if you leave the input label outside of the <label> element? For starters, people may experience your content in different ways. Some screen readers may not handle the label correctly, leaving users confused.
And since the <label> element is both programmatic and visual, using it correctly has benefits for all users. For example, when a user taps your label on a touchscreen, their browser will focus on the entire associated input — not just on the text. That may make your input easier for users to activate.
By understanding how HTML labels affect the user experience, you can make better decisions (and write cleaner code). For more accessibility guidance, send us a message or get started with a free automated website analysis.
