label · WCAG 4.1.2 Name, Role, Value · Level AHow to fix the “label” accessibility issue
The axe-core label rule fails when a form <input>, <select> or <textarea> has no associated label. Screen-reader users then reach a field they cannot identify. WCAG 2.2 (4.1.2 / 3.3.2, Level A) requires every control to have a name.
What axe-core checks
axe-core fails any form control with no <label> linked via for/id, no wrapping label, and no aria-label/aria-labelledby. A placeholder alone is not a label.
Which standard this maps to
| WCAG 2.2 | 4.1.2 Name, Role, Value (Level A) |
| EN 301 549 | 9.4.1.2 |
| BFSG / EAA | BFSG § 12 via EN 301 549 · EAA Annex I |
| Category | Forms & Labels |
Why it matters
A checkout with unlabelled fields — email, address, card — is the highest-stakes accessibility failure on a shop: the user literally cannot complete the purchase. It is Level A and trivially demonstrable, which is exactly what a BFSG complaint targets.
Common causes
- Inputs using only
placeholderas the label - Custom-styled fields where the visible label is a plain
<div> - Search boxes with an icon button but no field label
- Labels present but not linked via
for/id
How to fix it
Associate a <label> with the control via matching for and id, or wrap the input in the label. Use aria-label only when a visible label is not feasible.
<!-- Fails: placeholder is not a label -->
<input type="email" placeholder="Email">
<!-- Passes -->
<label for="email">Email</label>
<input id="email" type="email">FAQ
No. Placeholders disappear on input and are not exposed as the accessible name. Use a real label.
Yes — keep it in the DOM and hide with a visually-hidden class, or use aria-label. Do not use display:none.
Find every issue like this on your site
Run a free WCAG 2.2 AA scan — real axe-core engine, no signup. Or get a timestamped evidence report for €29.