Search topics
Form field labels and hints only in a title tooltip
A gift card form puts each box's name, or the number of digits it takes, in a title attribute, which the browser shows only while a mouse pointer rests on the box.
title="Gift card number" The problem
Keyboard and touch users see empty boxes, with no words to say which is which or how many digits each one takes.
A shop's checkout has a Gift card section: two empty boxes side by side and an Apply button. The design leaves no room for labels, so each box's name went into a title attribute. Rest the mouse pointer on the first box and a small tooltip says "Gift card number"; rest it on the second and it says "PIN". A screen reader user who presses Tab hears "Gift card number, edit text". A sighted person who presses Tab sees focus land in an empty box, and nothing else appears. On a phone there is no pointer to rest, so no tooltip shows at all. Which box takes the 16-digit card number and which the 4-digit PIN is a guess. Many forms get as far as printing the labels and then leave the format in the title: "16 digits" and "4 digits" show only under a resting mouse pointer, so keyboard and touch users never see them.
3.3.2 Labels or Instructions asks for labels or instructions wherever a form needs input, and its Understanding page says they may give the format a field expects, especially when there are specific rules for correct input. A title is advisory text that desktop browsers show as a tooltip while a mouse pointer rests on the element. Reaching the box with Tab or tapping it shows nothing, and the HTML standard itself warns that relying on title leaves out keyboard-only and touch-only users. In the first form, the only words that tell the two boxes apart are in their titles, so for everyone without a mouse, the form has no labels at all. W3C's technique for naming a field with title, H65, is meant for fields whose purpose is already clear from what is on screen, such as a search box beside a Search button. Here, nothing on screen tells the boxes apart.
The accessibility tree looks complete. A field with no label, aria-label or aria-labelledby takes its accessible name from its title, so each box has a name, and 4.1.2 Name, Role, Value is met. What fails is what people can see. In the second form, the labels are on screen and the title becomes each field's description instead, so a screen reader reads "16 digits" after the name. But the shop takes only that many digits, so the count is an instruction people need before they type, and the screen shows it only to a mouse. The HTML standard asks for a title describing any pattern attribute, which is one way a format ends up only there.
On a phone or a tablet, no one can rest a pointer on a box, so the labels and formats are missing for everyone using touch, disabled or not.
3 of 10 groups affected
- No vision (not affected)
- Low vision (affected)
- Colour vision (not affected)
- No hearing (not affected)
- Hard of hearing (not affected)
- No speech (not affected)
- Motor (affected)
- Reach, strength (not affected)
- Cognitive (affected)
- Seizures (not affected)
- Limited manipulation Keyboard users Tab into each box and no tooltip appears, so the form is two empty boxes and an Apply button.
- Limited vision With the page zoomed in or magnified, a box shows no words; finding its label means resting the pointer on it, waiting for the tooltip and reading it wherever the browser draws it.
- Limited language, cognitive and learning abilities People who find forms hard have to work out which box is which, and remember a format from a tooltip that goes as soon as the pointer moves.
A screen reader test of the first form passes: every box is read with its name. axe's label rule counts the title as a name and passes the fields. Its label-title-only rule does flag a field named only by its title, but it is tagged as a best practice, with no WCAG criterion, so a scan limited to the WCAG tags skips it. EaseWeb's audit runs it as a lead for review. No automated rule judges whether a title on a labelled field holds an instruction the screen never shows. The audit lists such titles as leads, and a person decides whether the words are needed. Asked to "add labels", an AI assistant may add an aria-label with the same words: the field is named a second time, and the screen still shows nothing.
Try it
Tab into each gift card box: can you tell what it wants? Then rest the mouse on it.
Broken 1: nothing on screen names the boxes. Below the form, compare what a screen reader hears with what you can see. On a phone, tap a box.
Broken 2: the labels are printed, but how many digits each box takes is still only in its tooltip.
Apply a fix. Tab through again: is every word the screen reader says now on screen?
Broken Can you fix this?
Screen reader says:
(Tab to a box)
The fix
Print each label and format on screen, in a label element or in a hint tied on with aria-describedby.
- 1Every field has its label printed on screen, not only in a title.
- 2A format or instruction a field needs is printed too, in the label or beside it.
- 3Leave no words in a title that the screen doesn't show.
A title as the only label
<form class="gift-card"> <h2>Gift card</h2> <input name="card" inputmode="numeric" title="Gift card number"> <input name="pin" inputmode="numeric" title="PIN"> <button type="submit">Apply</button></form>A label and a hint under it
<form class="gift-card"> <h2>Gift card</h2> <label for="card">Gift card number</label> <p id="card-hint" class="hint">16 digits</p> <input id="card" name="card" inputmode="numeric" aria-describedby="card-hint"> <label for="pin">PIN</label> <p id="pin-hint" class="hint">4 digits</p> <input id="pin" name="pin" inputmode="numeric" aria-describedby="pin-hint"> <button type="submit">Apply</button></form>Nothing on screen says which box is which. The names are in the titles, so they show only under a resting mouse pointer. A screen reader reads them as the fields' names, but people looking at the form never see them.
Each box has a label tied to it by for and id, and its format on a short line under the label, which aria-describedby ties to the field. Everyone gets the same words. They are printed on screen, a screen reader reads the label as the field's name and the hint as its description, and clicking the label puts the cursor in the box. The titles are gone, so no words are left only in a tooltip.
Both print every word a field needs, and both pass 3.3.2. A hint under the label suits an instruction of more than a few words. It keeps the label short, which matters for voice control users, who say the label to reach the field, and for screen reader users, who hear the name on every visit. It can also take its own quieter style. How a description is read, at once or after a pause, depends on the screen reader. The format in the label needs no ARIA and reaches every screen reader as part of the name. Choose it when the format is two or three words, as it is here.
Remove the title. A title that repeats the label adds a tooltip with words already on screen, and one that says anything more is a hidden message again. One exception: with a pattern attribute, the HTML standard asks for a title that describes the pattern, and browsers may use it in their "match the requested format" message. Keep that title identical to the printed hint, or replace the browser's message with an error of your own tied to the field, as form errors that don't say how to fix them shows.
Instructions that appear on focus. The W3C's Understanding page for 3.3.2 allows instructions that appear only while the field has focus. A hint can appear on focus as well as on hover, stay until focus leaves, and close with Escape, as long as the label itself is always on screen; tooltips that vanish on approach and can't be dismissed covers what such a pop-up needs. A title can't do this, because browsers don't show it on focus.
Accept what people type. The card prints its number in groups of four, so take it with the spaces and remove them, rather than adding "no spaces" to the hint: convert what people type instead of rejecting it.
Other places a title shows up. These are covered elsewhere.
- An icon-only button with a
titledoes get a name from it, but sighted keyboard and touch users still see only the icon. Naming those buttons is covered in icon-only buttons with no accessible name. - An
iframeneeds itstitle: it names the frame for screen readers, and nothing about it needs to be seen. See iframes with a missing or generic title. - A placeholder used as a label is the other common way a label goes missing from the screen. It is covered in form fields with missing or mismatched labels.
Components. Make the label a required prop of the shared field component, and the hint a prop that prints visible text and wires up its id and aria-describedby together. Leave title out of the props, so a hint can't end up in a tooltip.
Design ideas
A format can sit anywhere on the field, as long as it is there before typing.
Four ways to show that the gift card number takes 16 digits. Tab into each field and type a few digits, then try the same on a phone: two show the format before you type, and two keep it back until you hover or get it wrong.
In the design file
- Each field three ways: empty, part-filled and filled, with its format still on screen in all three.
- Put the format on the field or right beside it, never only behind an icon.
- Write the hint’s contrast ratio beside its colour, at least 4.5:1 for text this size.
- Use the same words for the format before typing as in the error message.
Passes
- A format pill inside the field A soft pill at the field’s end says “16 digits”, #4a4541 on #f1ede9 at 8.13:1. It is there at rest, stays while digits go in and once the field is full, and needs no extra line under the field.
- A count that fills as you type Under the field’s end, “0 of 16 digits” in #5c5650 at 7.24:1, counting up as digits go in. The format is on screen before typing, and the count shows how many are left; it is read with the field, not on every key.
Fails
- An ⓘ icon that shows the format on hoverWCAG 3.3.2 A small ⓘ after the label, #5c5650 at 7.24:1, opens a dark card saying “16 digits” while the pointer rests on it. Tab never reaches the icon, so with a keyboard the field is just its label.
- The format shown only after a wrong tryWCAG 3.3.2 At rest the field says nothing about digits. Type a few digits, fewer than 16, and leave it, and a red line appears, “Enter all 16 digits”, #b3261e at 6.54:1: the rule was there from the start, but the screen shows it only once someone has broken it.
Verify the fix
4 checks, no mouse.
Test with: Keyboard, Touch, Screen reader, Zoom
Record the OS, browser and assistive-technology versions, the build, the date, and the actual result of each step. Repeat after the shared field component changes.
How screen readers handle aria-describedby, title (no label) and title (with a label)
Limits
This is a starting pattern, not a guarantee for every application. It covers labels and instructions a field needs in order to be filled in. Help that explains where to find something, such as which number on the card is the PIN, is a separate Level AAA topic, "Forms offer help beside the fields that need it", which has no guide yet. Fields added by payment iframes, third-party widgets or content editors need the same check. Test the complete journey with your target assistive technology.
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.
References
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.