Form field without a label (label)

The label rule flags text fields, checkboxes, radio buttons and text areas that have no accessible name, so a screen reader announces "edit text" and nothing about what to type. The fix is a visible <label> connected to the field – with for and id, or by wrapping the field in the label.

What the rule means

Every form field needs a name that assistive technology can read out, and it should match the label people see. The rule looks at <input> (except hidden inputs and buttons, which have their own rules) and <textarea>. It passes a field that gets its name from any of these:

• a <label> whose for matches the field's id, or a <label> wrapped around the field,
• aria-label or aria-labelledby,
• a title or a placeholder attribute.

It fails a field with none of them, and a field whose only label is hidden with display: none, because that hides it from screen readers too.

Note what passes: axe accepts a placeholder as a name, because browsers expose it as one. A placeholder is still not a label. It disappears as soon as someone types, it is usually light grey, and people with memory or attention difficulties lose track of what the field was for. Whether a field's label is good enough is a judgement the rule does not make – which is why the fact box above says "partly".

Who is affected

Blind people using a screen reader hear "edit text, blank" and have to guess. Voice-control users cannot say "click Email address" when the field has no name. People with cognitive disabilities, and anyone filling in a long form on a phone, rely on labels that stay visible. Missing form labels are among the most common failures on the web: the WebAIM Million 2026 found them on 51.0% of the top one million home pages ^[5].

Why the check fails

• Text next to the field in a <span>, <div> or <p> that looks like a label but is not connected to it.
• Search boxes in the header with only a magnifying-glass icon beside them.
• A for that points nowhere – the field's id was changed or generated by a component library, and the label was not updated.
• Page builders and form plugins that print the label text as a heading above the field.
• Labels hidden with display: none to keep a compact design, which removes them from the accessibility tree.
• Newsletter and cookie-banner forms injected by third-party scripts.

How to fix it

1. Give every field a visible label and connect it: for on the label, the same value as id on the field.
2. Where the design really has no room for visible text – a search field with a clearly labelled button – hide the label visually with a CSS class, not with display: none.
3. Fix it in the form component or template, so every form that uses it is fixed at once.

<!-- Before: the text looks like a label, but nothing connects it -->
<span class="form-label">Email address</span>
<input class="form-input" type="email" name="email">
<div class="form-label">Your message</div>
<textarea class="form-input" name="message" rows="4"></textarea>

<!-- After: each label is tied to its field with for and id -->
<label class="form-label" for="contact-email">Email address</label>
<input class="form-input" id="contact-email" type="email" name="email">
<label class="form-label" for="contact-message">Your message</label>
<textarea class="form-input" id="contact-message" name="message" rows="4"></textarea>

A search field whose button already says "Search" can keep its label off screen:

<!-- The label is hidden visually, not from screen readers -->
<form class="site-search" role="search" action="/search/">
  <label class="visually-hidden" for="site-search-q">Search the shop</label>
  <input id="site-search-q" type="search" name="q">
  <button type="submit">Search</button>
</form>

/* Visually hidden, still read by screen readers */
.visually-hidden { position: absolute; width: 1px; height: 1px; overflow: hidden; clip-path: inset(50%); white-space: nowrap; }

How to test it manually

1. Click on each label text. If the cursor does not jump into the field, the two are not connected.
2. Open the accessibility pane in your browser's developer tools (Chrome, Edge, Firefox) and select the field: the "Name" should match the visible label.
3. Type into each field. If the only hint vanishes, the field relies on a placeholder – add a real label.
4. With a screen reader (NVDA on Windows, VoiceOver on macOS), Tab through the form and listen: does each field say what to enter, and whether it is required?

Related WCAG criterion

The rule is mapped to three criteria, and a field without a name usually touches all three: 1.3.1 Info and Relationships, because the link between text and field that people see is not in the code; 3.3.2 Labels or Instructions, because nobody is told what to enter; and 4.1.2 Name, Role, Value, because the control has no name. All three are Level A. Related: 2.5.3 Label in Name – the name in the code must contain the words of the visible label, or voice control breaks.

How Reviseberg reports it

Reviseberg runs label on every crawled page at 1280px. The issue list shows the rule with its severity, its WCAG criteria and level, the number of fields and pages affected, and the points you get back by fixing it. The detail view gives the CSS selector, the HTML snippet and every page the field appears on – a header search box shows up on every page, and one template fix clears all of them.

You can mark a finding as "ignore", "can't fix" or "false positive" with a reason; every decision is logged. A clean result here never marks 1.3.1, 3.3.2 or 4.1.2 as passed: whether the labels say the right thing is a person's check, recorded as a manual result.

Related rules

• undefined – the same problem on a <select> drop-down.
• undefined – custom fields built with ARIA roles that have no name.
• undefined – fields about the user whose autocomplete value is invalid.
• undefined – submit and reset buttons without text.

Find every unlabelled form field on your site – get a free scan