Accessible Form Labels

Labels are a foundational part of any accessible form. Without properly implemented, users who rely on screen readers have no way to understand what a field is asking for. A label does two things: it tells the user what a field is for, and it connects that meaning to the input in the code so assistive technology can announce it. There are a number of basic form label accessibility rules all developers should follow to build accessible forms.

Use the <label> element

Every input needs a visible, programmatic label. The most reliable way to label an input is with the HTML element, linked to the input using matching for and id attributes. Example is below:

<label for="email">Email address</label>
<input type="email" id="email" name="email">

In the example above, the first line is the label of the form field. With the proper for and id, we can programmatically link the tag to the tag. Additionally to linking the label, when the for and id values match, clicking or tapping the label text also moves focus to the input.

When a visible label isn't practical

Some designs use a search bar with a button, or a compact inline form, where a visible label would feel visually cluttered. In those cases, use aria-label or aria-labelledby to provide a label programmatically without showing it visually.

<!-- aria-label: attach a label string directly to the input -->
<input type="search" aria-label="Search the site">
<!-- aria-labelledby: point to an existing element on the page by its id -->
<h2 id="signup-heading">Create your account</h2>
<input type="email" aria-labelledby="signup-heading">

Use aria-labelledby when label text already exists on the page. It references that text by id, so screen readers announce it without duplication.

Placeholder text is not a label

This is one of the most common labeling mistakes. Placeholder text disappears the moment someone starts typing, screen readers don't reliably announce it as label text, and its low contrast often fails WCAG minimums. It can hint at expected format (like "MM/DD/YYYY"), but it must never stand in for a real label.

<!-- Wrong: no label, placeholder only -->
<input type="text" placeholder="Full name">
<!-- Right: visible label + placeholder as a format hint -->
<label for="dob">Date of birth</label>
<input type="text" id="dob" name="dob" placeholder="MM/DD/YYYY">

Marking required fields

If a field is required, mark it in two ways: in the code and in the visible label.
Add required (or aria-required="true") to the input so assistive technology announces it. Then add visible text — like "(required)" — next to the label so sighted users also see it.

<label for="name">Full name (required)</label>
<input type="text" id="name" name="name" required>

A red asterisk alone is not sufficient. Screen readers may not announce it, sighted users may not know what it means without a legend, and color alone never conveys meaning in an accessible way. If you do use an asterisk, include a visible legend near the top of the form — for example, "Fields marked with * are required" — and wrap the asterisk in so screen readers skip it and rely on the required attribute instead.

<p>Fields marked with <span aria-hidden="true">*</span> are required.</p>
<label for="phone">Phone number <span aria-hidden="true">*</span></label>
<input type="tel" id="phone" name="phone" required>

Keep labels close to their inputs

Sighted users scan forms by proximity. Labels should appear directly above or immediately to the left of their input, not below and not far away. This also helps users who zoom in on a page, since distant labels may scroll out of view.

Label groups of related inputs

For radio buttons, checkboxes, and other grouped inputs, use

<fieldset> and <legend> to label the group as a whole. Each individual option still needs its own <label>.
html
<fieldset>
  <legend>Preferred contact method</legend>
  <input type="radio" id="contact-email" name="contact" value="email">
  <label for="contact-email">Email</label>
  <input type="radio" id="contact-phone" name="contact" value="phone">
  <label for="contact-phone">Phone</label>
</fieldset>

Without <fieldset> and <legend>, a screen reader user hears "Email, radio button" with no context about what they're choosing.

Conclusion

Accessible forms are not an edge case or a nice-to-have, they are a baseline requirement. The labeling practices covered in this article are some of the most impactful changes you can make, because labels are the foundation everything else builds on. A form without proper labels fails before a user even has a chance to fill it out.