Tooltip

Designs that leave only icons on screen created a problem. Dropping the words saves space and looks tidier, but what the icon does stays in the head of whoever built it. A square with an arrow in it could be export, share or upload, and the drawing doesn't settle which. Two people on the same team will read it two ways.

Writing the label on screen alongside costs the space back. A toolbar with eight buttons and a line of explanation under each one leaves less room for the actual work. Ask users and they'll say they don't know what an icon means; add the labels and daily users get text they stop reading on day two. Both complaints are legitimate and they point in opposite directions.

A tooltip shows that explanation only to whoever asked for it. Nothing is there by default, and a line appears for the person who moved a pointer onto it. People who know keep working and only the people who don't get an answer, and that is what defines the component. It costs the expert nothing and the newcomer one second.

A small box appears next to an element while the pointer rests on it and disappears when the pointer leaves. Five things have to be decided.

1. Decide what gets one. Icon buttons with no label and text cut off with an ellipsis are the main candidates. Buttons that already carry a written name don't get one — that's the same words twice, and it trains people to ignore the boxes.
2. Decide the delay. Instantly means a box popping out of every element a pointer crosses; too late and the person is already looking elsewhere. Somewhere around 0.3 to 0.5 seconds of rest is the convention, sometimes with a rule that makes subsequent tooltips in the same toolbar appear immediately, since by then the person is clearly reading them.
3. Cap the length. One to two lines, usually under about forty characters. Longer than that and reading it while holding a pointer still becomes work, and the content probably belongs in a help article instead.
4. Decide which way it opens. Near a screen edge the box gets clipped, so the rule has to flip it above, below or to the side depending on available space. A clipped tooltip is worse than none, because the person now knows something was there.
5. Decide what happens without a pointer. Touch screens have no hover, and someone using only a keyboard has to get the same information when focus arrives. This is the component most often missing from keyboard navigation, because the hover version works fine for everyone testing it.

That last item is the component's largest constraint. Information that exists only in a tooltip may never reach touch users or people using a screen reader, which reads screen contents aloud. So only put things here that the task can succeed without. Anything genuinely required goes on the screen, where it cannot be missed by anyone.

Clusters of unlabelled icons come first. Editing toolbars, the sort controls in a table header, the overflow button at the end of a row — anywhere meaning has to travel as a picture. These are also the places where a toolbar would otherwise double in height.

Revealing truncated text is second. A list title cut off with an ellipsis shows in full on hover. It earns the most on values that only differ at the end, like filenames: "Q3 2026 report draft" and "Q3 2026 report final" clipped to the same width can't be told apart without looking.

Defining numbers and abbreviations is third. A question mark beside a figure on a metrics screen, showing one line about what that number counts and which users it includes. This is the smallest unit of progressive disclosure, revealing information only when it's wanted.

There are places it must not be used. First, a warning someone needs before pressing doesn't belong in a tooltip. If deletion can't be undone, that sentence belongs on the screen or inside a modal. Second, input format guidance here is invisible exactly when someone is typing; password requirements stay written under the field, visible while the field is being filled in. Third, don't put links or buttons inside one. The box can vanish while the pointer travels toward the thing you wanted pressed, and in that case a different component is required — one that stays open until it's dismissed.

"Add a tooltip to this icon. I can't tell what the button does."

Asking for an explanation on an unlabelled icon, usually after guessing wrong once.

"Put that in a tooltip and mobile users never see it."

The information wouldn't reach an environment with no pointer, which is most of the traffic.

"Don't put a link inside the tooltip. Make it a popover."

If there's something to operate inside, it's a different component by definition.

Noa made this call while tidying the Pagedeck editing toolbar. Six of its eight buttons were icon-only, and in a usability test three of five participants failed to find the insert-table button. Two of the three said afterwards that they had seen the icon and assumed it did something else.

She added tooltips to all eight, and for two of them decided a tooltip wasn't enough and kept a written label as well. Attaching a tooltip does not by itself make an icon recognizable. Mia supported that call with usage records from the two buttons people reached for most, which showed both were used several times per editing session.

The most common mistake is treating an added tooltip as a finished explanation. The information is on the screen now, so it feels handled. But this box only opens for people who came looking. Someone who was never curious about an icon doesn't hover over it and goes on not knowing the feature exists. If the icon itself is hard to read, the answer isn't a tooltip — it's a label on the screen, or a different icon.

Reading it as an accessibility feature is the other one. It provides an explanation, so it looks helpful. But built carelessly this component subtracts from accessibility instead. Show it only on hover and keyboard users never get the information; draw the box without exposing it to assistive technology and it doesn't exist for people listening. From the standpoint of accessibility — designing so people can use a product regardless of disability or circumstance — this component is something to audit, not something to count as progress.