In one paragraph
Form elements must have labels means a tested input or textarea did not meet the rule's accessible-naming checks. Provide a clear associated label, preferably visible and persistent, and keep extra instructions separate. A placeholder or title may satisfy some automated fallback paths without making the form well labelled. Verify the computed name, visible guidance, and interaction rather than relying on a presence-only pass.
Why it matters
People need to understand what a field asks for before, during, and after entering a value. A programmatically associated native label supports naming and can expand the useful click area, particularly for checkboxes and radio inputs.
A placeholder is usually a poor replacement for persistent instructions: it disappears as content is entered and can have low contrast. An ARIA-only name can help assistive naming but does not automatically provide every sighted user with the visible information needed to complete the task.
WCAG naming and visible labels or instructions address overlapping but distinct needs. Group labels, required-state information, error handling, and input-purpose hints also need review. One labelled textbox does not establish accessible completion of the entire form.
How WebAuditOS evaluates this finding
The supplied axe label rule concerns applicable input and textarea elements; selects and some input-button types have neighbouring rules. It accepts native associations and supported ARIA or fallback naming paths, including the documented placeholder and title paths.
Critical impact maps to high severity in the supplied integration. Computed naming depends on DOM relationships and accessibility rules, not only a non-empty attribute. Hidden or broken associations can matter, and a passing fallback does not confirm persistent visible guidance, correct purpose, or usable error messaging.
How to fix it
- Identify the actual rendered control and its question. Inspect its computed accessible name, visible label, and any error or help text. Check repeated form instances and responsive variants.
- Prefer an explicit native association. For example:
<label for="contact-email">Email address</label>
<input id="contact-email" name="email" type="email" autocomplete="email" aria-describedby="email-help">
<p id="email-help">We use this address to reply to your request.</p>Use truthful instructions for the real process. The label supplies the name; the description supplies additional context.
- Keep IDs unique and for values matched to the intended control. Copying a component with the same ID can attach several visible labels to the wrong field or make targeting inconsistent.
- For a group of related options, use suitable native grouping such as fieldset and legend where appropriate, while naming each option. A group heading alone is not a complete substitute for individual choice names.
- Retain placeholders only as supplementary examples when useful. Do not remove a persistent label after typing, or rely on an inaccessible floating-label implementation that loses association or contrast.
- If a compact design requires visual hiding, use a deliberate technique and inspect the resulting name. display:none commonly removes ordinary label exposure, but explicit hidden-node naming references have specific computation rules; avoid claiming every hidden relationship is universally invalid.
- Test focus, click-to-focus, voice use where available, required indicators, validation errors, and form completion with a keyboard and suitable assistive technology. Connect error descriptions without replacing the field's actual name.
- Rescan and review the whole journey manually. Check empty, prefilled, error, and dynamically added fields, not only the initial registration screen.
What the fix can break
Changing IDs can affect CSS, tests, autofill heuristics, and JavaScript selectors. Update dependencies and verify submission while repairing associations.
Adding aria-label without checking precedence can override a useful visible label with different wording. Prefer native relationships when they fit.
A label can be present and misleading. Do not declare the task complete merely because the control now announces something; it must announce the right question and retain understandable instructions.
Questions
Is a placeholder an adequate permanent label?
Not as a general design strategy. Some automated naming paths accept it, but persistence and visible guidance still need evaluation.
Must all names come from a label element?
No. Other supported naming methods exist, but a visible associated native label is often the most robust ordinary-form choice.
Does this rule cover select elements too?
The supplied integration exposes a separate select-name finding for them. Review both where the form contains both types.
Which related checks help?
Review button names, the automation limits guide, and the website audit checklist.
What severity does this get in the report?
High. An axe finding's severity comes from the impact axe reports for the element that failed, and the report maps critical and serious to high, moderate to medium, minor to low. This rule is declared critical in axe-core, so a failure arrives as high. That is why the panel above states a conformance level rather than a severity - for other axe rules it depends on what failed.