Form Labels: Why aria-label Counts for Accessibility

23 September 2026 · AI Web Page SEO

Every form input needs an accessible name so screen readers can announce it. Visible form labels are not the only option: a label for attribute, a wrapping label, aria-label, aria-labelledby or a title attribute all count. Placeholder text does not count as a label.

Screen readers announce a form field by its name. An input with no name is announced as just "edit text", and the user has to guess what to type. That's why form labels matter: accessibility guidelines require every input to have an accessible name. But a visible <label> tag isn't the only way to give one, and some accessibility checkers get this badly wrong in both directions.

What counts as a form label

An input has an accessible name if any of these is true:

A <label for="…"> points to the input's id.
The input sits inside a <label>, e.g. <label>Town <input type="text"></label>.
It has an aria-label attribute, e.g. aria-label="Your name".
It has aria-labelledby pointing to another element's text.
It has a title attribute (a weak fallback, but valid).

Buttons such as type="submit" are named by their text or value, so they don't need a label.

Why placeholder text isn't a label

A placeholder like "Your name" disappears as soon as someone starts typing, is often low-contrast, and isn't reliably announced by all screen readers. It's a hint, not a label. If your design only has room for a placeholder, add an aria-label with the same text.

How checkers get form labels wrong

Some HTML checkers use a shortcut: they check whether the page contains any <label> tag. That fails in two directions:

False alarms. A page whose inputs all use aria-label, with no <label> tags at all, gets flagged as "N inputs with no labels", although every one is correctly named.
Missed problems. A page with one proper label and one completely unlabelled input passes, because a <label> exists somewhere.

We found exactly this in our own HTML Checker: it flagged a homepage's comment boxes (which have aria-labels) while missing a genuinely unlabelled field on a test page. The fixed version checks each input individually against all five methods above.

Autocomplete: the related quick win

While you're adding labels, add autocomplete attributes too. autocomplete="name", "email" or "tel" lets browsers fill fields from saved details. It helps everyone, especially people who find typing difficult, and it tells password managers what each field is for.

<input id="c-name" type="text" placeholder="Your name"
       aria-label="Your name" autocomplete="name">

Checking your forms

Automated checks

Run your page through an HTML and accessibility checker that tests each input on its own. It should list the specific inputs that lack a name, not just a count.

A quick manual check

Tab through your form with a screen reader running (VoiceOver on Mac, NVDA on Windows). Each field should announce what it's for. If you hear "edit text" with nothing else, that field needs a label.

Summary

Every input needs an accessible name, from a label tag, a wrapping label, aria-label, aria-labelledby or title. Placeholders don't count. Visible labels are best, aria-label is fine where there's no room, and autocomplete attributes are an easy extra. When a checker flags your form, confirm it's checking each input, not just whether a label exists somewhere on the page.

Frequently asked questions

Does aria-label count as a form label for accessibility?

Yes. An input has an accessible name if it has an aria-label attribute, such as aria-label set to Your name, even if there is no visible label tag on the page. Other accepted methods are a label element whose for attribute points to the input's id, an input wrapped inside a label element, aria-labelledby pointing to another element's text, and a title attribute, which is a weak fallback but still valid. Visible labels are the best choice, but aria-label is fine where the design has no room for one. Buttons such as submit buttons are named by their text or value, so they do not need a separate label.

Why is placeholder text not a substitute for form labels?

A placeholder is a hint, not a label. Placeholder text such as Your name disappears as soon as someone starts typing, is often shown in low contrast, and is not reliably announced by all screen readers. That means a field relying only on a placeholder may be announced as just edit text, leaving the user to guess what to type. If a design only has room for a placeholder, the fix is to add an aria-label attribute with the same text, so the field keeps an accessible name. Adding an autocomplete attribute at the same time also helps browsers and password managers understand what the field is for.

How can I check whether every input on my form has an accessible name?

Use two approaches. First, run the page through an HTML and accessibility checker that tests each input individually and lists the specific inputs that lack a name, not just a total count. Checkers that only look for any label tag on the page can raise false alarms on inputs named with aria-label and can miss a genuinely unlabelled field when a label exists elsewhere. Second, do a quick manual check by tabbing through the form with a screen reader running, such as VoiceOver on Mac or NVDA on Windows. Each field should announce what it is for. If you hear edit text and nothing else, that field needs a label.