HTML label tag and what screen readers hear

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 <label> 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?

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 <span> 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 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 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 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 <span aria-hidden="true"> 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.

If you would rather not write labels by hand, the 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.

<!-- Explicit: for matches the input's id. Works anywhere on the page. -->
<label for="full_name">Full name</label>
<input type="text" id="full_name" name="full_name" autocomplete="name" required>

<!-- Implicit: the input sits inside the label. No id needed. -->
<label>
  Email address
  <input type="email" name="email" autocomplete="email" required>
</label>

<!-- A required marker people see, kept out of the spoken name. -->
<label for="order">Order number&nbsp;<span aria-hidden="true">*</span></label>
<input type="text" id="order" name="order" required>

<!-- A checkbox: wrap it, so the whole sentence is the click target. -->
<label><input type="checkbox" name="agree" value="yes"> I agree to be contacted about this order</label>

Did a label read differently for you?

If a screen reader or browser names one of these fields differently from what we measured, write to support@formgong.com. We will rerun the case and add it to the table.