Form Inputs Need Visible Labels

What Is This Issue?

Every form control needs an accessible name, and there is more than one way to supply it. An aria-label gives a control a name in the accessibility tree, so a screen reader will announce it. The catch is that aria-label renders nothing on screen. When a field relies on it alone, a sighted user has no visible text telling them what to type. This check, AC-039, fires when an input has an aria-label but no associated visible <label> element.

Teams often reach for aria-label to pass an automated accessibility scan quickly, because the scanner sees an accessible name and stops complaining. That satisfies the machine but not the human. Accessibility is not only about screen readers: people with low vision, attention or memory differences, and anyone completing a long form all rely on a label that stays put while they work.

Why This Matters

Placeholders are the usual culprit. A greyed hint inside the field looks like a label until the user starts typing, at which point it disappears. If they pause, get interrupted, or return to review their answers, the context is gone and they must clear the field to remember what it wanted. Low contrast placeholder text also fails color contrast requirements on its own.

Visible labels address several WCAG success criteria at once. Criterion 1.3.1 Info and Relationships expects the label and field relationship to be programmatically available. Criterion 2.4.6 Headings and Labels expects labels to describe purpose. Criterion 3.3.2 Labels or Instructions expects instructions when content requires user input. A persistent, properly associated label satisfies all three, and it enlarges the clickable or tappable area because clicking the label focuses the field, which helps users with motor impairments and everyone on touch screens.

Ways to Name a Field, Ranked

Not every naming method is equal. The table shows what each approach provides.

How to Detect

1. Look at the form with fresh eyes: does every field have text next to or above it that stays visible while you type?
2. Run axe DevTools and review any rule about form elements lacking a visible label.
3. In the console, list inputs with document.querySelectorAll('input[aria-label], select[aria-label], textarea[aria-label]') and check whether each also has an associated visible label.
4. Tab to each field and confirm a screen reader announces a name that matches the visible text.

How to Fix

1. Add a <label> for each input and connect them with matching for and id attributes, or wrap the input inside the label.
2. Move the wording that lived in aria-label or the placeholder into that visible label.
3. Keep the placeholder only for a format example such as name@example.com, never as the sole label.
4. If space is tight, a visually compact but still visible label is fine; do not hide it with display:none, which also removes it from the accessibility tree.
5. Re-test to confirm the visible text and the announced name match.

A Note on Floating Labels and Search Fields

Floating label patterns, where the placeholder animates up to become a label on focus, can be accessible if the label remains a real, visible element after interaction and is associated with the input. A magnifier icon on a search box is a common exception people cite, but even there a visible or clearly implied label is better than an icon alone. When in doubt, show the label.

Related reading on SEO ProCheck: the full accessibility checks library, why links must have discernible text, and the rule that role text must not contain focusable elements.

Frequently Asked Questions