About this AccessLint rule
When a form field has more than one <label> element associated with it, screen readers may read only one of the labels, read them in an unpredictable order, or ignore some of them entirely. The behavior varies across assistive technology and browser combinations, so there is no reliable way to ensure that all labels are announced correctly. This makes the form harder to understand for screen reader users, who depend on label announcements to know what information a field expects.
A <label> can be associated with a form field either by wrapping the field or by using a for attribute that matches the field's id. If two or more <label> elements reference the same field through either mechanism, the field has multiple labels.
This rule relates to WCAG success criterion 4.1.2 (Name, Role, Value) at Level A. That criterion requires that all user interface components have a name that can be programmatically determined. When multiple <label> elements compete for that role, the programmatically determined name becomes ambiguous, and the result depends on implementation details of each browser and screen reader pairing.
How to fix it
The fix depends on why multiple labels exist.
If the labels contain separate pieces of information that both describe the field, combine them into a single <label> element. Use <span> elements inside the label if you need to style the pieces differently.
If one label is the primary name for the field and the other provides supplementary instructions (such as format hints or constraints), keep the primary <label> and move the supplementary text into a separate element referenced by aria-describedby. Screen readers will announce the label first, then the description, giving users all the information without the ambiguity of duplicate labels.
If the extra label was added by accident or through a templating error, remove it.
Examples
Incorrect: two labels pointing to the same field
<label for="email">Email</label>
<label for="email">Required</label>
<input type="text" id="email">
Both <label> elements have for="email", so the input has two labels. A screen reader might announce only "Email" or only "Required", depending on the implementation.
Correct: single label with all necessary text
<label for="email">Email (required)</label>
<input type="text" id="email">
All information is in one <label>, so the accessible name is unambiguous.
Correct: single label with supplementary text via aria-describedby
<label for="email">Email</label>
<input type="text" id="email" aria-describedby="email-hint">
<span id="email-hint">Required. Use the format name@example.com.</span>
The field has one <label> for its accessible name and a separate element for the supplementary hint. Screen readers announce the label as the field name and the aria-describedby content as the description.
Correct: styled pieces inside a single label
<label for="email">
<span class="label-text">Email</span>
<span class="label-required">*</span>
</label>
<input type="text" id="email">
Even though the text is split across <span> elements for styling purposes, there is only one <label> wrapping them, so the accessible name is clear.
Detect accessibility issues automatically
Rocket Validator scans your site with complementary accessibility engines, helping teams find issues across every page.
Help us improve our guides
Was this guide helpful?
๐
Trusted by teams worldwide
Validate at scale.
Ship accessible websites, faster.
Automated HTML & accessibility validation for large sites. Check thousands of pages against WCAG guidelines and W3C standards in minutes, not days.
Scheduled Reports
API Access
Open Source Standards
$7
/ 7 days
Pro Trial
Full Pro access. Cancel anytime.
Start Pro Trial โ
Join teams across 40+ countries