# HTML label tag and what screen readers hear
How the label element names a field, why for has to match the id, what placeholder and aria-label change, and what a label never sends.
Author: Formgong
Published: 2026-11-03
Language: en
Canonical: https://formgong.com/en/blog/html-label/
The label element gives a form field its name: a screen reader reads it, and a click on it moves focus to the field. Tie it with for matching the input's id, or put the input inside the label. In our test on 3 November 2026, 2 of 10 fields came through with no name at all, and the label text reached the server in 0 of 10.
## Why does a field with text next to it still have no name?
Your form looks labelled. The word “Phone” sits right above the phone field, and “City” is right beside the city field. Then someone tabs through it with a screen reader and hears “edit text, blank” twice, or clicks the word “Phone” and nothing happens. The words on screen and the name the browser gives the field are two different things, and only the `` element connects them.
We built one form with ten fields, each named a different way, including the mistakes we see most in pasted code. Then we read back the accessible name of every field in Chromium 153, Firefox 155 and WebKit 26.6, clicked each label, and posted the form to a local copy of Formgong's form backend to see what the server and the notification email get.
## What name does each kind of label give a field?
Accessible names read with Playwright's aria snapshot in Chromium, Firefox and WebKit, 3 November 2026. All three browsers gave the same name in 10 of 10 rows, and Chromium's own accessibility tree agreed.
How the field was namedName a screen reader gets
`` matching the input's id“Full name”
Input inside the label“Email address”
`for="phone-number"`, input id is `phone`No name at all
Placeholder only“Company”, taken from the placeholder
Plain text next to the input, no labelNo name at all
Visible label “Postcode”, `aria-label="ZIP"`“ZIP”: the aria-label wins over the visible words
Two labels for one input, “Order number *” in the first“Order number * (on your receipt)”, star included
Label hidden with a screen-reader-only class“Search the help pages”
Checkbox wrapped in its label“I agree to be contacted about this order”
“Nickname” with the star in `aria-hidden`“Nickname”
The two empty rows are the ones to look for in your own code. A `for` that points at an id nobody has, here `phone-number` against `phone`, links nothing, and the browser does not guess. Plain text in a `` beside a field is just text. Both look correct on screen, which is why they survive so long.
The placeholder row is a trap of a different kind. Browsers do fall back to the placeholder for the name, so a screen reader hears “Company”. But the placeholder disappears as soon as someone types, so a sighted visitor who comes back to check the field has nothing to go on. Our [accessible contact form checklist](/en/blog/accessible-contact-form/) covers that in the WCAG terms. And the aria-label row shows the opposite risk: it replaced the visible word “Postcode” with “ZIP”, so a voice-control user who says “click Postcode” gets nowhere. Keep the name and the visible words the same.
## What does clicking a label do?
A click on a label moves focus to its field, or ticks it if the field is a checkbox or radio. In our test that worked for 4 of 5 text labels in all three browsers. The one that failed was the broken `for`. A second label for the same field worked too, so “(on your receipt)” after the order number field was clickable.
For a checkbox, the label is most of the click target. In Chromium the box itself measured 13 by 13 pixels and the wrapping label 273 by 17, and a click on the words ticked the box. On a phone that difference decides whether people manage to tick it on the first try. The same works for radio options, which our [HTML radio button](/en/blog/html-radio-button/) article tested.
## Does the label text reach the server?
No. We filled all ten fields and sent the form, and the request held the ten `name` attributes with their values. The label text appeared in 0 of 10 cases. The notification email Formgong would send listed `full_name`, `q` and `nick`, because the field names are all the server ever sees.
So you are writing for two readers. The label is for the person filling in the form and can be a whole sentence. The `name` is for whoever reads the submission, so make it a word they will recognise in an email or a spreadsheet column, such as `phone` rather than `field_3`. Our article on [how HTML forms work](/en/blog/how-html-forms-work-low-level/) shows the full request the browser builds from those names.
## Should the required star go inside the label?
If you put it in as plain text, it becomes part of the name. Our order number field was read as “Order number * (on your receipt)”, and a screen reader may read the star aloud. Wrapping the star in `` kept it on screen and out of the name, which came through as plain “Nickname”. The `required` attribute already tells assistive technology the field is required, so nothing is lost.
## Can a form generator write the labels for you?
The markup below shows both ways of tying a label, with the star kept out of the spoken name. It posts to Formgong, a form backend that sends each submission to your email or Telegram, once you add the form's action and key from the [HTML forms docs](/en/docs/html/).
If you would rather not write labels by hand, the [HTML form generator](/en/tools/html-form-generator/) gives every field an id and a label tied to it with `for`, labels each radio and checkbox option, and puts the required star in an `aria-hidden` span, which is the pattern that read as plain “Nickname” in our test. Both competitor guides we read on 3 November 2026, Formspree's “Mastering the HTML Label Element” from 23 March 2025 and Static Forms' label tag guide from 9 May 2026, explain explicit and implicit labels well, but neither mentions what a required star does to the spoken name, and both leave the writing to you. One limit on our side: Formgong's notification shows your field names, not your labels, so the generator builds each `name` from the label text to keep the email readable.
```html
Full name
Email address
Order number *