"Form elements must have labels": how to label every input in your sign-up and checkout forms

Updated Oct 27, 2026 · Pewterkit Guides

"Form elements must have labels" means an <input>, <select> or <textarea> has no programmatic label, so a screen reader announces "edit text" with no hint of what to type. Give each field a visible <label> connected by for and id (in React, htmlFor), or wrap the input inside its label. Placeholder text alone doesn't count as a lasting label.

Why it matters

The axe rule label says "Screen readers users require useful form labels to identify form fields", and rates the impact Critical. It maps to WCAG 4.1.2 Name, Role, Value (Level A). Labels help mouse and touch users too: clicking a label puts the cursor in its field.

The US Department of Justice's web guidance lists inaccessible forms among common barriers: people may not be able to fill out and submit forms without "Labels that screen readers can convey to their users", which for an app means sign-ups and checkouts that some customers can't finish.

The fixes, best first

1. A label tied by for and id (recommended):

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

In React and JSX the attribute is htmlFor:

<label htmlFor="email">Email address</label>
<input id="email" type="email" autoComplete="email" />

2. Wrap the input in its label:

<label>Email address <input type="email" name="email"></label>

3. aria-label, when the purpose is already clear visually (a search box next to a magnifier button):

<input type="search" aria-label="Search recipes">

4. aria-labelledby, when visible text elsewhere already names the field:

<h2 id="news">Get the newsletter</h2>
<input type="email" aria-labelledby="news">

Axe lists placeholder last and calls it "not a recommended solution as the visual label (the placeholder text) will be removed once the user enters text."

Keep each id unique on the page; two fields with id="email" (a header sign-up and a footer sign-up) break the link for one of them.

Prompt for your app builder

Check every input, select and textarea in the app. Each one needs a visible
<label> linked with htmlFor/id (unique ids), or an aria-label where a
visible label would be redundant, such as a search box. Keep placeholders
as hints only. Don't change the visual design beyond adding labels.

What Pewterkit Check looks for

A free check reads your homepage's server HTML and lists inputs that have no label it can connect to them in the HTML (a <label>, aria-label, aria-labelledby or title). It counts a placeholder as a name, because browsers use it as one, so a placeholder-only field isn't flagged even though a visible label is better. When the server HTML is an empty app shell, it makes no claim, because the form only appears after JavaScript runs.

FAQ

Is placeholder text a label?

It gives a field a name in some cases, but the axe guidance doesn't recommend it, because the text disappears as soon as someone types.

Can I hide the label visually?

Yes, when the design needs it. W3C's forms tutorial says "The label can be hidden visually, though it still needs to be provided within the code": keep the <label> and hide it with a visually-hidden CSS class, or use aria-label. Screen readers still announce it, though most users prefer visible labels.

Do hidden inputs need labels?

<input type="hidden"> isn't shown or announced, so it needs no label. Buttons such as type="submit" are named by their text instead; see buttons must have discernible text.

Why does my checker say "input missing associated label" when there's text above the field?

Text near a field isn't connected to it. Turn that text into a <label> with a matching for and id.

Sources

  1. W3C WAI Forms Tutorial: Labeling Controls — read 27 Oct 2026: for/id, wrapping labels, aria-label, aria-labelledby, visually hidden labels
  2. axe rule label: Form elements must have labels (Deque University) — read 27 Oct 2026: impact, fixes in order of preference, placeholder caveat, WCAG 4.1.2
  3. Guidance on Web Accessibility and the ADA (ADA.gov, U.S. Department of Justice) — read 27 Oct 2026: inaccessible forms as a barrier

How this page was made: drafted with AI from the sources listed, reviewed by Pewterkit. Docs checked Oct 27, 2026. Spotted something out of date? Tell us.

Related guides