In one paragraph
Form field must not have multiple label elements is an automated review-rule label, not a universal HTML prohibition. HTML permits more than one label associated with a control. Inspect whether the resulting name and visible guidance are deliberate, clear, and usable. The supplied WebAuditOS report omits this rule's review results, so no finding does not validate multiple labels or require their automatic removal.
Why it matters
A field can have several associated label elements, and accessible-name computation can combine their text. That can be intentional, but accidental duplication may create repetition, contradictory wording, or inconvenient voice targets. Evaluate the actual outcome rather than assuming every client chooses a random label.
Common causes include a form-builder label plus a wrapper component's label, a required marker implemented as a separate label, or copied IDs connecting unrelated text. These are implementation problems to review, not evidence that a field is allowed only one naming source in every valid design.
A useful distinction is the question versus instructions, required state, and errors. Ordinary native labelling can carry the question, while appropriate description relationships carry supplementary help. Do not collapse every piece of information into a long repeated name.
How WebAuditOS evaluates this finding
The supplied form-field-multiple-labels rule gathers applicable native label associations and has special handling for visibility and explicit naming. Multiple labels can yield human-review results rather than violations.
The source states that this rule does not produce findings in the current violations-only report. Its nominal moderate impact is not a reported medium-severity item here. A control with no label can also escape this particular rule while failing the separate naming check.
How to fix it
- Inspect each actual label association, ID, and wrapping relationship in the rendered DOM. Distinguish intentional multiple labels from repeated component output or duplicate identifiers.
- Read the computed accessible name and compare it with the visible question. A standards-permitted structure may still be verbose or misleading in the actual interface.
- Remove accidental duplicates without deleting needed information. A simple field-and-help pattern is:
<label for="work-email">Work email</label>
<input id="work-email" name="email" type="email" aria-describedby="work-email-help">
<p id="work-email-help">Use the address where you want to receive replies.</p>Use truthful content and add any required or error handling as appropriate. The description is not a substitute for the field's name.
- If multiple labels are deliberate, retain them only after reviewing the combined name, click-to-focus behaviour, voice interaction, and supported assistive combinations. Do not remove an intentional association solely to satisfy the rule's wording.
- Use unique IDs for repeated forms and update source generators. Two different controls sharing an ID can create cross-field confusion that merging label text does not solve.
- Model required indicators and grouping properly. A required asterisk or a fieldset legend need not become another independent label pointing at the same input. Preserve meaningful instructions and state.
- Test empty, populated, validation, and responsive states. A visually hidden alternate label can remain part of naming depending on its actual mechanism and explicit references; inspect computation rather than guessing from CSS alone.
- Record manual review and rescan the ordinary label and ID checks. The supplied report's absence of this review-only finding is not evidence of clear field communication.
What the fix can break
Removing one label can remove useful wording or click area. Confirm the replacement still identifies the correct control persistently.
An aria-labelledby override may change which label text contributes. Avoid using it as a blind tool to hide duplicate generation while leaving confusing visible questions.
Do not present permitted HTML as automatically accessible either. The task is meaningful usable naming, not simply counting label tags.
Questions
Are multiple labels always invalid HTML?
No. HTML allows multiple label associations. Review the actual name and experience.
Why does the scanner not report every duplicate?
The supplied integration omits this rule's needs-review outcomes from its violations report.
Does a no-label field pass this review rule?
It can avoid this particular multiple-label condition but still fail ordinary naming requirements. Review the relevant label check.
Which related checks help?
Review form labels, unique IDs, and the automation limits guide.
What severity does this get in the report?
None, because the finding does not appear. Severity for an axe finding comes from the impact axe reports for the element that failed - axe declares this rule moderate, which we would map to medium. But in axe 4.13 this rule never reports a violation, only "needs review", and our report lists violations only.