Form controls require labels
ZMD005ZemDomu reports supported form controls that have no source-level accessible name. Associate visible label text with the control whenever possible, or use a valid ARIA naming relationship when a visible label is not practical.
What this rule catches
- Supported input, select, and textarea elements with no associated <label> and no ARIA name.
- Explicit label relationships whose for/htmlFor value does not match the control's id in the analyzed source.
What static analysis cannot prove
- A static scan cannot prove that a label is clear, complete, or appropriate for the surrounding form task.
- Runtime-generated ids, labels added by third-party widgets, and accessible names assembled only after rendering may require browser inspection.
Standards classification and detection confidence
- Classification
- normative — The rule checks whether supported form controls expose a source-level labeling relationship.
- Detection confidence
- context dependent — Explicit labels and resolved ARIA names are reliable evidence. Runtime-generated ids, labels, and component abstractions may require rendered inspection.
Applicable WCAG 2.2 criteria
Criterion 1.3.1 applies when the visual labeling relationship must also be programmatically determinable.
Normative means the rule checks a machine-testable part of a cited standards requirement. Advisory means it enforces a documented authoring convention or supporting technique. Neither classification makes a ZemDomu result proof of WCAG conformance.
Examples
✅ Good
<label htmlFor="email">Email</label>
<input id="email" type="email" name="email">
<label for="email">Email</label>
<input id="email" type="email" name="email">❌ Bad
<input type="email" name="email">React and Vue notes
- React/TSX
- In JSX and TSX, associate a visible label with htmlFor and the control's matching id; aria-label and aria-labelledby keep their hyphenated names.
- Vue
- In Vue templates, use the HTML for attribute with a matching id. Bind dynamic values carefully because a static scan may not be able to resolve their runtime result.
Quick summary
When: Input, select, or textarea lacks a matching <label> or ARIA name
Warning: Form control missing id or accessible label
Solution: Give the element an aria-label, aria-labelledby, or reference a <label for> to provide an accessible name
Why it matters
Accessibility: Unlabeled controls are announced as “edit” or “button” without context, making forms unusable for screen-reader users.
SEO: Search engines lose semantic context for form fields, reducing discoverability for interactive page elements.
Rule details
In brief
- Goal: Make form controls programmatically identifiable by assistive technologies.
- What to do: Associate each control with a visible <label> (using for/id) or provide an aria-label/aria-labelledby when no visible label exists.
- Why: Labels enable screen-readers to announce field purpose and allow clicking text to focus the control.
Intent
Prevent orphaned form controls by enforcing explicit label associations, improving navigation and user confidence.
Benefits
- Screen-reader users get clear field names instead of generic announcements.
- Keyboard and mouse users can click labels to focus inputs, enhancing usability.
- Search engines index form field names, aiding SEO for interactive elements.
- Mobile users benefit from larger click targets and reduced input errors.
Techniques
H44: Using <label> elements with for/id to associate text labels with form controls.G173: Providing an accessible name via aria-label or aria-labelledby when visible labels aren’t possible.
HTML Semantics
The <label> element and ARIA naming provide the control’s accessible name, forming the root of the accessibility tree for form fields.
References
Tips & edge cases
- Always use <label> where possible; it has broad support and binds click focus.
- For icon-only controls, prefer aria-labelledby referencing visible text rather than aria-label.
- Use automated accessibility checks (e.g., axe, pa11y) to flag missing labels early.