Search topics
Vague form labels that don't say what to enter
A gift card form labels its fields Name, Email and Date, one word each, so people can't tell whether it wants their details or the recipient's, or which date it means.
<label for="name">Name</label> The problem
People can't tell what to type into a field whose label is one generic word, so they enter their own details where the recipient's belong, or the wrong date.
A shop's gift card page is drawn calm: a preview of the card, and beside it four fields in one column, each labelled with one word: Name, Email, Date and Message. The designer kept the labels short so the form looks light next to the card, and to them each word is plain enough: it is a gift form, so the name is the recipient's.
A visitor buying a card for a friend reads "Name" and types their own, because almost every form they have filled in asks for theirs. "Email" gets their own address too, so the card arrives in their inbox, not their friend's. "Date" could be the date to send it, the friend's birthday or the visitor's own date of birth, and only one of them is right. Nothing on the form says which; the confirmation email, or a friend who never got a card, is the first sign of the mix-up.
A second build of the same drawing keeps the one-word labels on screen and adds the missing words for screen readers only, in a visually hidden span. A screen reader user now hears "Name (recipient)". Everyone who reads the screen still sees Name.
WCAG 2.4.6 Headings and Labels asks that headings and labels describe their topic or purpose. It doesn't ask for long labels: the Understanding page says a word, or even a single character, may be enough if it gives the right cue. But "Name" on a form that is about two people is not a cue to either of them, and "Date" fits three different answers. The labels exist and are tied to their fields, so the form passes 1.3.1 and 3.3.2; what fails is the words.
Hidden text doesn't change that. WCAG defines a label as text presented to the user to identify a component, and the label sighted visitors are presented with is still Name. The Trusted Tester test for 2.4.6 reviews the labels and instructions given for each field, and the ones on screen still don't say what to enter.
2.4.6 covers headings too; headings chosen by size, not by structure deals with those. This guide is about form labels.
The guess is hardest where a form asks about two people, or two things of the same kind: gift cards, bookings made for someone else, delivery and billing addresses, an emergency contact. On a phone, the card preview that hints at the answer is pushed above or below the form, so even people who could have worked it out from the picture don't see it.
3 of 10 groups affected
- No vision (affected)
- Low vision (affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (not affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Limited language, cognitive and learning abilities Each one-word label leaves a guess: whose name, which email, the date of what. People who find guessing hard, or who take a form at its word, type their own details, because most forms ask for yours.
- Without vision Moving by Tab, a screen reader reads each label and skips the heading and the card preview around the fields, so "Name, edit text" is all there is to go on.
- Limited vision Under a magnifier, only a field and its label are in view. The heading and the card preview that hint at whose name it is are out of sight.
Every field has a label element tied to it, so axe, ANDI and every other label check pass the form. No rule can tell whether "Name" is the right word, because that depends on what this form asks. The EaseWeb audit sends a field labelled only with a word that rarely says enough on its own, such as Number, Date or Code, and two fields in one form with the same label and no legend apart, to a person as a lead to read, not as a failure. Asked to fix a vague label, AI coding tools can add aria-label="Recipient's name" or hidden text, which is the second Before below: the screen reader hears the purpose, and the screen still says Name.
Try it
Fill in the gift card form as if you were buying a card for a friend.
Before you type, decide whose name and email each field wants, and which date. The card preview shows what the shop does with each answer. Tab through the fields and compare the label on screen with what a screen reader hears, especially in Broken 2.
Broken Can you fix this?
Emailed to …, on ….
Screen reader says:
(Tab to a field)
The fix
Write the missing words into each visible label, or put short labels under a legend that says whose they are.
- 1Every visible label, read with its group's legend, says what to enter.
- 2Two fields never share a label unless a legend tells them apart.
- 3The words that say what to enter are on screen, not only in the code.
One-word labels, as drawn
<form> <label for="name">Name</label> <input id="name" name="recipient-name" type="text"> <label for="email">Email</label> <input id="email" name="recipient-email" type="email"> <label for="date">Date</label> <input id="date" name="send-date" type="date"> <label for="message">Message</label> <textarea id="message" name="message"></textarea> <button type="submit">Buy gift card</button></form>The missing words in each label
<form> <label for="name">Recipient's name</label> <input id="name" name="recipient-name" type="text"> <label for="email">Recipient's email</label> <input id="email" name="recipient-email" type="email"> <label for="date">Date to send</label> <input id="date" name="send-date" type="date"> <label for="message">Message</label> <textarea id="message" name="message"></textarea> <button type="submit">Buy gift card</button></form>Why this fix: Write labels that make sense on their own
Every field is labelled, and every label is tied to its field. The code knows what each one is for, recipient-name and send-date; the labels people read say only Name and Date.
Each label now says what to enter on its own, wherever it is read: on screen, by a screen reader, in an error message ("Enter the recipient's email") or by voice control ("click Recipient's email"). The design keeps its single column, its type and its spacing; each label grows by a word or two and still fits one line at phone width. "Message" stays as it was: on a gift form, there is only one message it can mean.
Both pass 2.4.6. Put the words in each label: it does the same job with no extra structure, and the label is the one piece of text that travels without its surroundings. An error summary, a "check your answers" page and voice control use the field's own label without the heading above it, so "Recipient's email" stays clear there and "Email" does not. Use a legend when a form asks the same things about two people or places, such as a gift form that also asks for the sender's name and email, or delivery and billing addresses, where "Recipient's" and "Your" in front of every label would make the form heavy; then write the group's words into the error messages and the review page yourself. Either way, a field that no group explains, like the date, needs its own words. Hidden text and aria-label are not a third option: they reach the screen reader and leave the screen as it was.
The recipient's fields are not about the person filling in the form, so they take no autocomplete="name" or autocomplete="email": the browser would offer the buyer's own details there, the same mix-up the vague label made. 1.3.5 asks for those tokens only on fields that collect information about the user; see form fields that block or break autofill.
Keep the label for what the field is, and the format for a hint. "Date to send" says which date; how to type it, if the field isn't a native date input, goes in a line under the label tied to the field with aria-describedby. A placeholder is no place for either, because it disappears as soon as someone types.
A legend is read with the fields inside it, and some screen readers repeat it with each one, so keep it to a few words, "Who it's for", not a sentence of instructions. Put longer guidance in a paragraph before the group, tied to the first field with aria-describedby if it matters there.
In a shared field component, the label is a prop that a code review will pass whatever it says. Review label wording with the content, and keep the note on what each field holds next to the component's use, so the next person to edit the form can tell whether the label still fits.
Fixing this with an AI coding assistant? Get this guide as Markdown, or get every guide in your coding agent.
Design ideas
A label can be friendly, or short, as long as it says what to enter.
Four more ways to label the gift card form’s fields. Read each label as if it were the only thing on screen, and say what you would type: two tell you, and two leave you guessing.
In the design file
- Write each label as it will appear on the site, “Recipient’s name”, because the developer copies what is drawn.
- Next to each field, note what goes in it and whose it is, “the recipient’s name, printed on the card”. Reviewers and translators need it.
- Draw the longest label on a 390-pixel phone screen, so the layout fits the real words.
- When a form asks about two people, draw a heading over each person’s fields as part of the form.
- Reuse the label’s words in the error message, “Enter the recipient’s email”.
Passes
- Labels written as questions “Who is the card for?” reads like the shop talking and names whose details it wants, so people don’t type their own. Set in the ink, #1f2d2b at 14.30:1, at the size of a small heading; keep each question to one line at phone width.
Rule of thumb: Write labels that make sense on their own
- One heading over day, month and year The heading says which date, “Date to send”, a line in #5b6764 (5.88:1) gives an example, and each box is labelled with its part. The boxes can be as narrow as the numbers they hold, because the heading carries the meaning.
Fails
- Only the format as the labelWCAG 2.4.6 DD, MM and YYYY over three neat boxes look precise, and say how to write a date but not which one: the day to send the card, the friend’s birthday and the buyer’s own date of birth all fit.
- Labels cut short to fit the gridWCAG 2.4.6 A tidy grid gives every label the same narrow column and ends the long ones with an ellipsis, so “Recipient’s name” and “Recipient’s email” show as “Recipient’s n…” and “Recipient’s e…”: the word that told them apart is gone. Draw the column for the longest label, or put the labels above the boxes.
Verify the fix
4 checks, no mouse.
Test with: Screen reader
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat when fields are added or relabelled, and when the form is translated.
Limits
This is a starting pattern, not a guarantee for every application. It covers the words a label uses, not whether the label exists or is tied to its field (form fields with missing or mismatched labels), how required fields are marked (required fields marked only by colour), or the hints and formats a field may need beyond its label. Whether a label is clear depends on the people who use the form and what they already know, so test it with them, in every language the form ships in.
This is a recreated teaching example, not a finding about a named client. The code is a starting pattern: test it in your own product. No completed assistive-technology test is claimed here.
Keep this fixed as your code changes.
Turn guides like this into rules your coding agents and CI follow, then have the result retested with a keyboard and screen readers.