Check your form fields for missing labels

SiteCurl checks every visible form input, select menu, and textarea on your pages for an accessible label. It looks for five types of labels: a <label for> element pointing to the input's ID, a wrapping label element, an aria-label attribute, an aria-labelledby attribute, or a title attribute.

The check skips hidden inputs, submit buttons, and elements inside aria-hidden containers (like honeypot fields). These are intentionally unlabeled. Everything else needs a label so screen readers can tell users what to type in each field.

SiteCurl reports how many inputs are on the page and how many are missing labels. You know the scope of the problem before you start fixing.

When a screen reader user tabs to a form field, the reader announces the field's label. If the label is 'Email address,' the user knows to type an email. If there is no label, the reader says something like 'edit text, blank.' The user has a text box in front of them and no idea what to put in it.

Placeholder text does not count as a label. Most screen readers do not read placeholder text when the field receives focus. Even in readers that do, the placeholder disappears as soon as the user starts typing. If they need to check what the field is for, the hint is already gone.

This is not a rare problem. The WebAIM Million study found that 45% of form inputs on the web are missing a proper label. Nearly half of all form fields on the internet are unusable for screen reader users.

Labels also increase the click target for all users. When a label tag is properly linked to an input, clicking the label text focuses the input. On a checkbox or radio button, this means the user can click the text instead of the tiny box. This helps everyone, not just screen reader users.

Forms are where conversions happen. Contact forms, sign-up forms, checkout forms, search boxes. If a form field has no label, screen reader users cannot complete the form. That is lost revenue, lost leads, and lost engagement.

Unlabeled form fields also cause problems for voice control users. Software like Dragon NaturallySpeaking lets users say 'click email' to focus the email field. If the field has no label, there is nothing to say.

There is a legal dimension too. Missing form labels are one of the most frequently cited issues in web accessibility lawsuits. They are easy to detect, easy to fix, and hard to defend when they are missing.

E-commerce sites with checkout forms are at the highest risk. A checkout form with unlabeled fields means screen reader users cannot complete a purchase. That is direct revenue lost.

SaaS products with sign-up and login forms need labels on every field. If the sign-up form is inaccessible, the product is unreachable for screen reader users before they even start the trial.

Contact forms on small business sites are often the primary conversion point. A form with two fields and no labels is two chances to lose a potential customer.

WordPress sites using form plugins (Contact Form 7, Gravity Forms, WPForms) sometimes generate inputs without labels, depending on how the form was configured. The plugin settings need to be checked, not just the visual output.

Step 1: Use label elements with the for attribute. This is the most reliable method. Give your input an ID, then create a label that points to it: <label for='email'>Email address</label> <input id='email'>. The for attribute must match the input's ID.

Step 2: Or wrap the input in a label. If you cannot use the for attribute, wrap the input inside the label tag: <label>Email address <input></label>. This links them without needing an ID.

Step 3: Use aria-label for visually hidden labels. If the design does not show a visible label (like a search box with only a placeholder), add aria-label='Search' to the input. The label is invisible but announced by screen readers.

Step 4: Check every form on your site. Do not just check the contact form. Check login forms, search boxes, newsletter sign-ups, comment forms, and any input in the sidebar or footer. Every input needs a label.

Step 5: Do not rely on placeholder text. Placeholders are hints, not labels. They disappear when the user types and are not reliably announced by screen readers. Use a visible label or aria-label in addition to any placeholder text.

Using placeholder text as the only label. Placeholder text is not announced by most screen readers when the field has focus. It also disappears when the user starts typing. Always use a real label element or aria-label alongside placeholders.

Pointing the for attribute to the wrong ID. If the label's for value does not match any input's ID, the label is not linked. Screen readers treat it as plain text, not a form label. Check that IDs match exactly.

Labeling the wrong field. If two fields share the same ID (which is invalid HTML), the label points to whichever one the browser finds first. Each input needs a unique ID.

Hiding labels with display:none. If you hide a label with display:none or visibility:hidden, screen readers skip it too. Use a visually hidden class (like sr-only) that keeps the element in the accessibility tree while hiding it visually.

After fixing, run another SiteCurl scan. The unlabeled input count should drop to zero. For a manual check, click on a label's text. If the cursor moves to the associated input, the link is working. If nothing happens, the for attribute is missing or wrong.

To test with a screen reader, Tab through your form. Every field should be announced with its label text. If you hear 'edit text, blank' or just the field type with no description, the label is still missing.

Every form field needs a label. Without one, screen reader users cannot tell what to type. Use label elements with the for attribute for the most reliable results. Check every form on your site, not just the obvious ones.