A lead form only works if the visitor understands each field. HTML form labels are the cheapest, fastest fix for that problem: they name an input, connect it to assistive technology, and give the visitor a stable anchor while typing. This guide shows how to pair labels with inputs, word them so people answer correctly, and keep them useful once validation kicks in.
Most form friction is not a design problem. It is an ambiguity problem. A visitor sees a box, guesses what belongs in it, types something plausible, and later gets an error. Clear labels prevent that guess. They also survive the moment a placeholder disappears, which is exactly when a nervous lead decides whether to keep going.
Pair every input with a real label
A label must be programmatically associated with its control. The two reliable patterns are the for attribute matching the input's id, or wrapping the input inside the <label> element. Both are covered in MDN's form data guide, whose examples pair each text input with a <label for="..."> and a matching id MDN form data guide.
<div>
<label for="work-email">Work email</label>
<input type="email" id="work-email" name="work_email" autocomplete="email">
</div>
Two practical rules keep this from drifting as a form grows. First, never reuse the same id twice on a page, because for resolves to the first match. Second, when you copy a field block, change both the id and the for together. A label with a broken for still looks fine on screen, so the bug usually hides until someone uses a keyboard or a screen reader.
Stop relying on placeholder-only labels
Placeholders are hints, not names. They vanish as soon as a character is typed, which leaves the visitor re-reading their own entry to remember what the field asked for. Placeholders also tend to be low contrast, and some people never see them at all.
A useful baseline:
- The visible
<label>states what is wanted. - The placeholder, if used, shows an example value such as
[email protected]. - Neither element carries information the other needs.
If you want the label to look minimal, style it small and quiet rather than removing it. Layout choices are reversible. Deleting the accessible name is not.
Word labels so the answer is obvious
Label text should set an expectation, not start a riddle. Compare "Phone" against "Phone number for a callback". The second tells the visitor why the field exists and roughly what to type.
A short checklist for wording:
- Use the field's real name, not internal jargon. "Company website" beats "URL" on a quote form.
- Add units where numbers are involved, for example "Budget in USD".
- Mark required and optional fields consistently. If most fields are required, label the optional ones instead of starring everything.
- Keep the label short enough to scan, and move extra explanation into helper text below it.
Put format hints in helper text, not the placeholder
When format matters, a persistent hint below the input beats a disappearing placeholder. Something like "Include the country code, for example +44 20 7946 0000" stays visible while the visitor types. If the hint is tied to the input with aria-describedby, assistive technology reads it too.
<p id="phone-hint">Include the country code, for example +44 20 7946 0000.</p>
<input type="tel" id="phone" name="phone" aria-describedby="phone-hint">
Keep hints to one sentence or line. Long explanations are better placed in the page copy above the form, where they can be read before the visitor starts.
Tie labels to validation messages
Validation is where labels pay off twice. When a browser blocks submission, the message and the highlighted field should use the same words the visitor just read. MDN's validation guide explains that required inputs block submission and display a default message such as "Please fill out this field", that only data you genuinely need should be required, and that marking required fields is expected practice under WCAG accessibility guidelines MDN form validation guide.
That gives you a simple rule: if the label says "Work email", the error should say "Work email is missing" or "Check the work email address", not "Field 3 invalid". For a fuller treatment of wording, placement and retry behaviour, our guide to contact form error messages walks through inline placement and a test script.
The same MDN guide demonstrates native attribute checks such as required, type, pattern, minlength and maxlength, which cover most conditional needs before any custom script is written. Labels and these attributes work together: the attribute decides what is valid, the label explains what was asked.
Group related fields with fieldset and legend
Choice sets and address-style blocks need a group name, not just individual labels. A <fieldset> with a <legend> gives the whole group a heading that a screen reader announces before each option. That matters most for radio buttons, where "Yes" alone is meaningless without knowing the question.
<fieldset>
<legend>Preferred contact time</legend>
<label><input type="radio" name="contact_time" value="morning"> Morning</label>
<label><input type="radio" name="contact_time" value="afternoon"> Afternoon</label>
</fieldset>
For a postal address split across several inputs, one legend such as "Your address" plus individually labelled lines keeps the form readable without repeating the word "address" five times.
A five-minute audit you can run today
Before you touch the design, test the labels themselves. Open the page and work through this list:
- Tab through the form. Every stop should be a control, and each should have a name you can see or hear.
- Click each visible label. Does focus land in the correct input? A clickable label is a quick proof that
forandidmatch. - Type into every field. Once text is entered, is it still obvious what the field wanted? If not, the placeholder was doing the label's job.
- Turn styles off or read it in order. Without CSS, the form should still read as a sequence of clear names and inputs.
- Trigger an error on purpose. Submit with a required field empty and check that the message names the field the same way the label does.
Any failure on that list is usually a one-line fix in the markup, not a redesign.
If keyboard behaviour in a popup is part of your lead capture flow, our accessible popup keyboard and focus checklist covers focus entry and close behaviour, and modal focus management provides a step-by-step test script.
Keep your label markup, connect the submission
Good label markup lives in your HTML and should stay there. WidgetJar does not replace your form fields or rename them. The detected form widget connects an existing HTML form on your registered site to WidgetJar, so the labels you have carefully written keep working while submissions are handled through the platform rather than a custom backend.
That separation is the practical point. Fix the labels first, because they decide whether a visitor starts filling the form. Then make sure the submit action actually delivers the data, using guidance such as how to make an AI-generated HTML form work without a backend and HTML form validation for static contact forms for the validation side. When your fields are clear and your submission path is connected, a lead form stops being a guessing game and starts being a conversation.