WCAG 1.3.1 / 4.1.2 — Info and Relationships / Name, Role, Value

Missing Form Labels

What is this issue?

Missing form labels occur when input fields, checkboxes, radio buttons, selects, and textareas lack a programmatically associated label. WCAG Success Criterion 1.3.1 (Level A) requires that information and relationships conveyed through presentation are available programmatically, and 4.1.2 (Level A) requires that all user interface components have an accessible name.

A visible label next to a field is not enough. The label must be associated with the input either through a `<label>` element with a matching `for` attribute, by wrapping the input inside the `<label>`, or by using `aria-label` or `aria-labelledby`. Without this programmatic association, screen readers announce the input as an unlabeled text field, leaving the user guessing what information is expected.

This issue is extremely common on sites that use placeholder text as the only label. While placeholders can provide hints, they disappear when the user starts typing, leaving no indication of what the field is for. They also have insufficient contrast in most browsers and are not announced consistently by all screen readers. Relying on placeholders alone fails both WCAG 1.3.1 and 3.3.2 (Labels or Instructions).

Impact on users

For screen reader users, an unlabeled form field is a guessing game. The screen reader may announce "edit text" or "text input" with no indication of whether it expects a name, email, phone number, or password. Users must either guess or try to infer the purpose from surrounding content, which is unreliable and time-consuming.

Voice control users (e.g., Dragon NaturallySpeaking) also depend on visible labels because they use the label text to target fields by voice. Without a label, they cannot say "click email" to focus the email field. Touch screen users benefit from labels as well, since clicking a label focuses its associated input, providing a larger click target.

Missing labels in critical forms like login, registration, checkout, and contact forms directly prevent users from completing key actions. This is not just an accessibility issue -- it also increases form abandonment rates for all users who find unlabeled fields confusing.

Code example

Before (non-compliant)

<!-- Placeholder-only, no label -->
<input type="text" placeholder="Full name">
<input type="email" placeholder="Email">

<!-- Label present but not associated -->
<span>Password</span>
<input type="password">

<!-- No label at all -->
<select>
  <option>Choose a country</option>
</select>

After (compliant)

<!-- Explicit label with for/id -->
<label for="name">Full name</label>
<input type="text" id="name" placeholder="e.g. Jane Smith">

<label for="email">Email</label>
<input type="email" id="email" placeholder="jane@example.com">

<!-- Wrapping label -->
<label>
  Password
  <input type="password">
</label>

<!-- Label for select -->
<label for="country">Country</label>
<select id="country">
  <option value="">Choose a country</option>
</select>

How Scrutia detects this issue

Scrutia inspects every form control on your pages and checks for a programmatic label association -- whether through a `<label>` element with a matching `for` attribute, a wrapping `<label>`, or ARIA attributes (`aria-label`, `aria-labelledby`). It also flags inputs that rely solely on placeholder text with no persistent label. Each finding includes the form field's location, its current state, and a code snippet showing how to add the correct label.

Check your site for this issue

Scrutia audits your site against WCAG criteria in minutes.

Free audit

Frequently Asked Questions

Can I use placeholder text instead of a label?

No. Placeholder text is not a substitute for a label. Placeholders disappear when the user types, have poor contrast in most browsers, and are not consistently announced by screen readers. Always use a visible <label> element and use the placeholder only as a supplementary hint.

When should I use aria-label instead of a <label> element?

Use aria-label only when a visible label is not appropriate for the design -- for example, a search input with a magnifying glass icon and no visible text. In most cases, a visible <label> element is preferred because it benefits all users, not just screen reader users.

Do hidden labels still count?

Yes, a visually hidden label (using a sr-only / visually-hidden CSS class) still provides an accessible name to screen readers. However, a visible label is always better because it helps sighted users, voice control users, and provides a larger click target.

How do missing labels affect form conversion rates?

Studies show that clearly labeled forms have higher completion rates. Users who cannot quickly identify what each field expects are more likely to abandon the form. Proper labels reduce errors and support faster form completion for everyone.

Does your site have this issue?

Scrutia scans your pages against WCAG success criteria and delivers actionable fixes. Results in 5 minutes.

Run a free audit