Fixing Form Labels

What a form label actually is

Every form control has an accessible name: the words assistive technology announces when the control receives focus. A screen reader reads it out, voice control software lets people say it to move to the field, and browsers use it alongside other hints when they autofill. A label is simply the most reliable way of giving a field that name, while also showing it on screen.

The browser works out the name from several possible sources, in a fixed order of priority:

1. aria-labelledby, pointing at the id of other text on the page;
2. aria-label, a text string on the field itself;
3. a <label> element connected to the field;
4. the title attribute;
5. for some fields, the placeholder, as a last resort.

That order explains several confusing results. A field can have a perfect visible label and still announce something else, because an aria-label added by a developer or plugin overrides it. And a field with only a placeholder may technically have a name in some browsers, yet still fail, because the visible text disappears as soon as someone types.

The WCAG criteria behind form label findings

Label patterns that work

Explicit label with for and id

<label for="enquiry-email">Email address</label>
<input id="enquiry-email" name="email" type="email" autocomplete="email">

The for value must exactly match the input's id, including capital letters. This is the most widely supported pattern. It also makes the label clickable, so tapping the words "Email address" puts the cursor in the box, which helps anyone with small targets or a shaky hand, and makes tiny checkboxes and radio buttons much easier to hit.

Wrapped label

<label>
  <input type="checkbox" name="newsletter" value="yes">
  Send me the monthly newsletter
</label>

Putting the field inside the label connects them without ids. It is valid HTML and works in current browsers and screen readers. Many teams still add for and id as well, because some older assistive technology handled the wrapped form less consistently and it removes any doubt.

A label you cannot see

Sometimes there is genuinely no room for visible text, such as a search box beside a magnifying-glass button in the header. Keep a real label element and hide it visually with a class that leaves it available to assistive technology:

<label for="site-search" class="visually-hidden">Search the shop</label>
<input id="site-search" type="search" name="q">
<button type="submit">Search</button>

.visually-hidden {
  position: absolute !important;
  width: 1px; height: 1px;
  margin: -1px; padding: 0; border: 0;
  overflow: hidden;
  clip-path: inset(50%);
  white-space: nowrap;
}

Do not hide labels with display: none or visibility: hidden. Those remove the text from most assistive technology as well as from the screen, and the field loses its click target. Hidden labels should be the exception; almost every field is easier for everyone with visible words beside it.

When aria-label or aria-labelledby is right

Use aria-labelledby when existing visible text already names the field, such as a table column heading above a quantity box. Use aria-label only when there is no suitable text at all and a hidden label is not possible. In both cases, keep the words close to what sighted users see, so voice control and screen reader users are talking about the same thing.

Why a placeholder is not a label

Placeholder-only forms are the most common cause of form label findings, especially in newsletter sign-ups, header search boxes and minimal contact forms. They look tidy, but they cause real problems:

• The text vanishes when someone starts typing, so anyone who is interrupted, or who has memory or attention difficulties, loses track of what the field was for.
• Placeholder text is usually pale grey and often fails the 4.5:1 contrast ratio needed for normal text.
• When a browser or password manager autofills the form, every placeholder is replaced at once and the person cannot check that each value went into the right box.
• Support for the placeholder as an accessible name varies, so some combinations of browser and assistive technology announce nothing useful.

Keep placeholders only for a short example of the expected format, such as placeholder="e.g. S40 1AB", with the real label shown above the field. If a design uses a "floating label" that starts inside the box and moves above it on focus, check that it is a real label element and that it never disappears.

Groups, hints and error messages

Radio buttons and checkbox groups

Each option needs its own label, but the question they answer needs a name too. Without it, a screen reader user hears "Yes, radio button, 1 of 2" with no idea what they are agreeing to.

<fieldset>
  <legend>How should we contact you?</legend>
  <input type="radio" id="contact-phone" name="contact" value="phone">
  <label for="contact-phone">Phone</label>
  <input type="radio" id="contact-email" name="contact" value="email">
  <label for="contact-email">Email</label>
</fieldset>

Screen readers announce the legend when focus first enters the group. Keep legends short, because some screen readers repeat them for each option. Use a fieldset for date-of-birth fields split into day, month and year boxes as well; each box still needs its own label such as "Day".

Hints and required fields

<label for="booking-ref">Booking reference (required)</label>
<p id="booking-ref-hint">Six letters and numbers, printed at the top of your confirmation email.</p>
<input id="booking-ref" name="ref" required aria-describedby="booking-ref-hint">

The label gives the name; aria-describedby connects extra help that is read after it. The required attribute tells assistive technology the field is mandatory. If you use an asterisk, explain it once at the top of the form, and consider writing "required" or marking optional fields instead.

Error messages

<label for="enquiry-phone">Phone number</label>
<input id="enquiry-phone" name="phone" type="tel" autocomplete="tel"
       aria-invalid="true" aria-describedby="enquiry-phone-error">
<p id="enquiry-phone-error" class="field-error">Enter a UK phone number, like 01246 000000</p>

Put the message next to the field, in text, and connect it with aria-describedby. Set aria-invalid="true" only while the error applies. A red border alone fails, because colour cannot be the only way information is shown. For long forms, a summary at the top listing each error as a link to its field helps everyone.

Fixing labels in common platforms

The fix, step by step

Edge cases the checker may raise

• Buttons are not labels. A submit button gets its name from its text, or from value on an input type="submit". An icon-only button, such as a magnifying glass, needs visually hidden text or an aria-label. That is a button naming problem rather than a label one, and our ARIA labels guide covers it.
• Custom dropdowns. Select menus rebuilt from div elements for styling often have no name, no role and no keyboard support. A native select with a label is simpler and more robust; if a custom control is essential, it needs a label connected with aria-labelledby as well as the correct roles.
• Hidden fields. Inputs with type="hidden" do not need labels. Spam traps, or honeypots, should be hidden from everyone with display: none or similar, so they never reach a screen reader or the keyboard.
• Several fields, one label. A single label cannot name two inputs. A phone number split into area code and number needs a label for each part, even if one is visually hidden, plus a fieldset or group name for the whole.
• Labels with links inside. A checkbox label such as "I agree to the terms" may contain a link. Clicking the link text should open the terms, not tick the box, so keep the link short and test both behaviours.
• Title attributes. A title can supply a name, but the tooltip it shows is not available to keyboard or touch users. Replace it with a label.

Stopping unlabelled fields coming back

• Build one input component. On custom sites, create a single field component that always renders a label, a unique id and optional hint and error slots, and use it everywhere.
• Set defaults in your form builder. Turn labels on in the global settings of the form plugin, so new forms start with them.
• Check third-party embeds before launch. Newsletter, booking and quote tools are added by marketing teams and often skip review. Test each one with the checker and a keyboard before it goes live.
• Include forms in release testing. Any change to a form, including a redesign that shortens it, should be tested with a screen reader for a few minutes.
• Keep the labels short and plain. Clear words such as "Postcode" help everyone, including people using translation tools and AI agents that read the page.