# Form field labels and hints only in a title tooltip

Source: https://easeweb.dev/learn/title-tooltips
Topics: Buttons and links > Labels and help show on screen, not only in a tooltip (WCAG 3.3.2)
The fix: Put every word a field needs on screen. Either give each box a label element and print its format on a line under the label, tied to the field with aria-describedby, or write the format into the label itself. Then remove the title attributes.
Test with: keyboard, touch, screen reader, zoom
References: https://www.w3.org/WAI/WCAG22/Understanding/labels-or-instructions.html https://www.w3.org/WAI/WCAG22/Techniques/html/H65 https://html.spec.whatwg.org/multipage/dom.html#the-title-attribute https://html.spec.whatwg.org/multipage/input.html#the-pattern-attribute https://www.w3.org/WAI/tutorials/forms/instructions/ https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/title

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.

## What happens

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.

## Why it fails

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.

## Who is affected

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.

## What automation and AI miss

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.

## Before: a title as the only label

```html
<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>
```

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.

## Before: the format only in a title

```html
<form class="gift-card">
  <h2>Gift card</h2>
  <label for="card">Gift card number</label>
  <input id="card" name="card" inputmode="numeric" title="16 digits">
  <label for="pin">PIN</label>
  <input id="pin" name="pin" inputmode="numeric" title="4 digits">
  <button type="submit">Apply</button>
</form>
```

The labels are on screen now, but "16 digits" and "4 digits" are still only in the titles. Only a mouse user who rests the pointer on a box ever sees them.

## After: a label and a hint under it

```html
<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>
```

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.

## After: the format in the label

```html
<form class="gift-card">
  <h2>Gift card</h2>
  <label for="card">Gift card number (16 digits)</label>
  <input id="card" name="card" inputmode="numeric">
  <label for="pin">PIN (4 digits)</label>
  <input id="pin" name="pin" inputmode="numeric">
  <button type="submit">Apply</button>
</form>
```

When the format is a few words, it can go in the label itself. The whole label becomes the field's name, so a screen reader reads the format together with it, and no description is needed. A long instruction would make a long name, read in full every time someone reaches the field, so keep this for a format of a few words.

## Which option to use

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.

## Implementation decisions

**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](/learn/accessible-form-errors) 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](/learn/hover-content) 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](/learn/rules-of-thumb#convert-not-reject).

**Other places a title shows up.** These are covered elsewhere:

- An icon-only button with a `title` does 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](/learn/icon-buttons).
- An `iframe` needs its `title`: it names the frame for screen readers, and nothing about it needs to be seen. See [iframes with a missing or generic title](/learn/frame-titles).
- 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](/learn/form-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.

## Verify the fix

1. Put the mouse aside and Tab through the form: every box shows its label and its format, in words, with nothing to hover.
2. On a phone, tap each field: the label and format are printed before you tap and stay printed after.
3. In the browser's accessibility tree, check each field's name comes from its label rather than a title, and that its format is in the name or the description. With a screen reader, check each field is read with the words printed beside it.
4. Zoom to 200%: each label and hint stays beside its box.

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.

## 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.

## What screen readers do (tested by hand by EaseWeb)

`title (no label)`: Advisory text the browser shows as a tooltip; on a field with no label, browsers make it the field’s name.

| Screen reader | Browser and system | Tab to it | Down Arrow |
| --- | --- | --- | --- |
| JAWS | Chrome, Windows 11 | Not tested | Not tested |
| NVDA | Chrome, Windows 11 | Not tested | Not tested |
| JAWS | Edge, Windows 11 | Not tested | Not tested |
| NVDA | Firefox, Windows 11 | Not tested | Not tested |
| NVDA | Edge, Windows 11 | Not tested | Not tested |
| JAWS | Firefox, Windows 11 | Not tested | Not tested |
| VoiceOver | Safari, macOS | Not tested | Not tested |
| VoiceOver | Safari, iOS | Not tested | Not tested |
| TalkBack | Chrome, Android | Not tested | Not tested |

`title (with a label)`: The same tooltip text on a field that has a label: browsers make it the field’s description.

| Screen reader | Browser and system | Tab to it | Down Arrow |
| --- | --- | --- | --- |
| JAWS | Chrome, Windows 11 | Not tested | Not tested |
| NVDA | Chrome, Windows 11 | Not tested | Not tested |
| JAWS | Edge, Windows 11 | Not tested | Not tested |
| NVDA | Firefox, Windows 11 | Not tested | Not tested |
| NVDA | Edge, Windows 11 | Not tested | Not tested |
| JAWS | Firefox, Windows 11 | Not tested | Not tested |
| VoiceOver | Safari, macOS | Not tested | Not tested |
| VoiceOver | Safari, iOS | Not tested | Not tested |
| TalkBack | Chrome, Android | Not tested | Not tested |

`aria-describedby`: Gives an element a description, such as a hint or an error, from text elsewhere on the page.

| Screen reader | Browser and system | Tab to it | Down Arrow |
| --- | --- | --- | --- |
| JAWS | Chrome, Windows 11 | Not tested | Not tested |
| NVDA | Chrome, Windows 11 | Not tested | Not tested |
| JAWS | Edge, Windows 11 | Not tested | Not tested |
| NVDA | Firefox, Windows 11 | Not tested | Not tested |
| NVDA | Edge, Windows 11 | Not tested | Not tested |
| JAWS | Firefox, Windows 11 | Not tested | Not tested |
| VoiceOver | Safari, macOS | Not tested | Not tested |
| VoiceOver | Safari, iOS | Not tested | Not tested |
| TalkBack | Chrome, Android | Not tested | Not tested |

https://easeweb.dev/learn/screen-reader-support

---

Get this guide in your coding agent: MCP https://easeweb.dev/mcp (setup at https://easeweb.dev/services/developers)