Guides › Fix guides

Missing form labels: fix guide (with examples)

Updated 2026-10-24 · Altlark guides

A form field with no label is an input, select or textarea that has nothing programmatically tied to it to say what it is. Sighted users may see "Email" written nearby, or a placeholder inside the box. A screen-reader user tabbing into the field hears "edit text, blank", with no idea what to type. Voice-control users can't say "click Email". People with cognitive disabilities lose the label as soon as a placeholder disappears on typing.

Contact forms, booking forms, newsletter signups and checkout pages are where this matters most, because a missing label can stop someone from completing the one task they came to do.

Which WCAG criteria apply

  • 1.3.1 Info and Relationships, Level A: the relationship between a label and its field must be available in code, not just visually.
  • 3.3.2 Labels or Instructions, Level A: "Labels or instructions are provided when content requires user input."
  • 4.1.2 Name, Role, Value, Level A: form controls need an accessible name.

Bad vs fixed: text next to a field

Before (flagged)
<p>Email</p>
<input type="email" name="email">

The word "Email" is just a paragraph. Nothing connects it to the input.

After (fixed)
<label for="email">Email</label>
<input type="email" id="email" name="email" autocomplete="email">

The for attribute must match the field's id exactly. A nice side effect: clicking the label puts focus in the field, which gives everyone a bigger click target.

Bad vs fixed: placeholder as the only label

Before (flagged)
<input type="text" name="name" placeholder="Your name">
<textarea name="message" placeholder="How can we help?"></textarea>

Placeholders aren't a reliable label. Some screen readers announce them and some don't, they disappear when you start typing, and they're usually low-contrast. Keep the placeholder for an example if you like, and add a real label:

After (fixed)
<label for="name">Your name</label>
<input type="text" id="name" name="name" autocomplete="name">

<label for="message">How can we help?</label>
<textarea id="message" name="message"></textarea>

Altlark flags placeholder-only fields with a note ("Has a placeholder, which isn't a reliable label") so you can find them quickly.

Bad vs fixed: a search box with no visible label

Sometimes a design has no room for a visible label, like a header search box with a magnifying-glass button. Use aria-label on the field, and give the button a name too:

Before (flagged)
<form action="/search">
  <input type="search" name="q">
  <button><svg aria-hidden="true">...</svg></button>
</form>
After (fixed)
<form action="/search" role="search">
  <input type="search" name="q" aria-label="Search the site">
  <button aria-label="Search"><svg aria-hidden="true" focusable="false">...</svg></button>
</form>

A visible label is still better where you can fit one: it helps everyone, not only screen-reader users.

Wrapping labels

You can also wrap the field inside the label. That works without ids, which is handy in templates:

After (fixed)
<label>
  Phone number
  <input type="tel" name="phone" autocomplete="tel">
</label>

Groups of radio buttons and checkboxes

Each radio button needs its own label, and the group needs a question. Use a fieldset and legend:

After (fixed)
<fieldset>
  <legend>Preferred contact method</legend>
  <input type="radio" id="c-email" name="contact" value="email">
  <label for="c-email">Email</label>
  <input type="radio" id="c-phone" name="contact" value="phone">
  <label for="c-phone">Phone</label>
</fieldset>

Watch out for duplicate ids

If two fields share the same id (common when a form is included twice on a page, for example in the header and the footer), <label for> can point at the wrong one. Altlark reports duplicate ids that are referenced by a label, aria-labelledby or aria-describedby as a separate error.

What Altlark checks exactly

Altlark looks at every <input>, <select> and <textarea> that isn't hidden from assistive technology. Input types hidden, submit, button, reset and image are skipped here (buttons are covered by the empty button check). A field counts as labeled if it has any of:

  • a <label for="..."> pointing at its id,
  • a wrapping <label>,
  • a non-empty aria-label or aria-labelledby,
  • a non-empty title.

Anything else is reported as "Form field with no label", with the element's selector and HTML snippet.

Limits

Altlark checks that a label exists, not that it's good. "Field 1" is technically a label but tells nobody anything. It also can't see forms that are injected by JavaScript (many embedded booking and chat widgets are), so test those by tabbing through them with a screen reader. Error messages, required-field indicators and timeouts also need manual review.

Testing it yourself

Open the form in Chrome or Firefox, right-click a field and choose Inspect, then open the Accessibility pane in dev tools. The "Name" shown there is what a screen reader will announce. If it's empty, or it shows the placeholder text, the field needs a label. For a real-world check, turn on VoiceOver (Cmd+F5 on a Mac) or install the free NVDA screen reader on Windows, then press Tab through the form: every field should be announced with a clear name and its type ("Email, edit text"). While you're there, submit the form with a required field left blank and listen for the error message. If the error is only shown in red, or appears somewhere the screen reader doesn't announce, that's another fix to make (WCAG 3.3.1 Error Identification), even though an automated scan can't detect it.

Why labels help everyone

A visible label that stays put while you type helps people who get interrupted, people using a phone in bright light, and anyone filling in a long form who needs to check what a field was for. Browsers also use labels and autocomplete values to fill forms automatically, which means fewer typos in the email addresses and phone numbers you collect.

Checklist

  1. Scan your contact, booking and checkout pages for free.
  2. Give every field a visible <label> where you can; use aria-label only where a visible label really doesn't fit.
  3. Don't rely on placeholder text.
  4. Group radio buttons and checkboxes with fieldset and legend.
  5. Add autocomplete values for personal details; it helps everyone fill the form faster.
  6. Re-scan, then submit the form once using only the keyboard.

Check your page for free

Altlark scans one public page in seconds and lists each issue with the element, the WCAG criterion and the fix. No signup.

Automated checks find some, not all, accessibility issues (they catch only a portion of WCAG problems). This is not legal advice, not a legal assessment and not a certification.

Related guides

All accessibility guides · Monitoring plans

More free tools from Swift Labs