How English Works | The Tooltip

A tooltip is a strange compromise.

The designer has something to say.

But not enough to deserve permanent space.

So the explanation waits.

You hover over an icon.

You move keyboard focus onto a control.

A small piece of English appears.

Download report

Or:

Shows changes since the previous version

Then you move away.

The words disappear.

This makes tooltip English different from labels, captions, forms and dialog boxes.

A tooltip is language that exists only at the edge of attention.

It is available.

But not continuously visible.

That makes it useful for secondary clarification.

It also makes it dangerous for essential information.

Quick Read

One-sentence answer: a tooltip works when a short piece of optional clarification becomes available on focus or hover without replacing the visible label, hiding essential instructions or demanding interaction the tooltip itself cannot support.

A good tooltip usually does a small number of jobs:

clarify: explain an unfamiliar icon, abbreviation or compact label;
expand: add a small amount of secondary detail;
confirm: tell the reader what a control means before activation;
reduce clutter: keep non-essential explanation available without filling the main interface;
support recognition: help a learner or newcomer translate an unfamiliar symbol into words.

W3C’s ARIA Authoring Practices Guide defines a tooltip as a popup that displays information related to an element when that element receives keyboard focus or the mouse hovers over it. W3C also notes that tooltip widgets themselves do not receive focus and that interactive content belongs in another pattern, such as a non-modal dialog. Importantly, as of August 2026, W3C explicitly marks its tooltip pattern as work in progress and says it does not yet have task-force consensus.

That caution is valuable.

A tooltip is not a universal solution for “we need somewhere to put more words.”

The Tooltip Is Not the Label

Suppose a form asks for:

Passport number

That is the label.

It identifies the field.

A tooltip might add:

Enter the number exactly as printed on the photo page.

The label carries primary meaning.

The tooltip carries secondary clarification.

Now imagine the visible field contains only:

Number

and the real explanation exists only inside a hover tooltip.

The interface has hidden the label that should have remained visible.

This is the first boundary:

Tooltips can supplement identity.
They should not be used to rescue a deliberately vague label.

The reader should not have to discover what a control is before deciding whether it deserves attention.

The Tooltip Is Also Not the Dialog

A tooltip is small and passive.

A dialog can contain a real task.

Suppose an icon needs only this explanation:

Copy link

Tooltip territory.

Now suppose the user needs:

a paragraph of explanation;
a checkbox;
a link;
a button;
a choice between settings.

That is no longer a simple tooltip.

W3C’s current tooltip guidance says tooltip widgets do not receive focus and notes that a hover container with focusable elements can instead be built using a non-modal dialog.

This gives us an excellent design test:

If the explanation needs a conversation, it is no longer merely a tooltip.

Tooltip English Is Secondary by Nature

Imagine a first-time user who never discovers the tooltip.

Can they still complete the essential task?

If no, the interface may have hidden something too important.

Essential information includes things such as:

required field rules;
major safety warnings;
the consequence of a destructive action;
the price of a transaction;
the main identity of a control;
the only route to recover from an error.

These should not depend on a user accidentally hovering over the correct pixel.

Tooltip English is best for:

extra context;
abbreviation expansion;
icon naming;
compact definitions;
brief explanations of unfamiliar terms;
secondary consequences that are useful but not task-critical.

The easiest rule to remember is:

If the reader must know it, do not make discovery optional.

Hover Is Not a Universal Human Action

Desktop mouse users can hover.

Touchscreen users often cannot hover in the same way.

Keyboard users navigate with focus.

Voice users may operate controls by accessible name.

Screen-reader users may encounter descriptions through programmatic relationships rather than visual popups.

This is why W3C’s tooltip pattern is triggered by keyboard focus as well as pointer hover.

Tooltips teach a larger digital-English lesson:

Never define the receiver as “a person with a mouse.”

The words may need to be available through several interaction paths.

The Tooltip Should Remain Long Enough to Be Read

Imagine a tooltip that disappears the instant the pointer leaves the trigger.

A reader with low vision may magnify the screen and need to move the pointer toward the tooltip to read it.

If the tooltip vanishes during that movement, the English technically appeared but functionally remained inaccessible.

W3C’s current pattern notes that when a tooltip is opened by pointer hover it should remain open while the cursor is over either the trigger or the tooltip, and that Escape should dismiss it.

This reminds us that reading takes time.

A message does not succeed merely because it was rendered.

It must remain available long enough for the receiver to perceive and interpret it.

Delay Changes the Feeling of the Interface

If every tooltip appears instantly as the pointer crosses the screen, the interface can become noisy.

Words flash everywhere.

The reader is constantly interrupted by explanations they did not request.

If the delay is too long, the reader may assume no help exists.

W3C describes tooltips as typically appearing after a small delay.

The timing creates an interaction threshold:

brief accidental hover → no interruption
deliberate attention → clarification appears

This is attention-sensitive English.

The interface waits for evidence that the reader wants more.

Tooltips Are Excellent for Icon Translation

Icons save space.

They also depend on convention.

A chain icon may mean:

link;
attach;
connect;
copy URL;
relationship.

A speech bubble may mean:

comment;
message;
chat;
feedback.

A tooltip can translate the compact visual sign into explicit English:

Add comment

That translation reduces the cost of learning the interface.

Over time the user may stop needing the tooltip.

The visual sign has become learned vocabulary.

This is almost exactly how children learn written words.

At first, the symbol requires conscious decoding.

Later, recognition becomes automatic.

But Familiar-Looking Icons Can Still Be Ambiguous

The temptation is to assume:

Everybody knows this symbol.

Everybody may not.

Age, culture, software experience and device history all influence icon literacy.

A floppy disk means Save to many users who have never handled a floppy disk.

A hamburger icon suggests a menu only if that convention has been learned.

A heart may mean favourite, like, save, health or romance depending on context.

Tooltip English is useful because it keeps the interface’s symbolic vocabulary teachable.

The designer can compress after preserving a route back to explicit meaning.

Abbreviations Are Another Natural Tooltip Use

A dashboard may contain:

Experts may know them.

Newcomers may not.

A tooltip can expand:

CTR — click-through rate

or, where useful:

CI — confidence interval: a range expressing uncertainty around an estimate

This creates a local bridge into specialised vocabulary without forcing the main interface to spell out every term repeatedly.

But again, the tooltip should not become an excuse for an interface made entirely of opaque initials.

If the user must read six tooltips before understanding one screen, the vocabulary architecture may be too compressed.

A Tooltip Can Explain a Constraint Before Failure

A password field has an information icon.

The tooltip says:

Use at least 12 characters.

Helpful?

Perhaps.

But if the user must know this rule in order to complete the field successfully, the rule may deserve persistent visible placement rather than optional discovery.

This is the difference between supplemental help and required instruction.

Better:

Password
At least 12 characters

Then the tooltip, if still useful, might explain:

Longer passwords are harder to guess. Use a unique passphrase you do not reuse elsewhere.

The essential constraint stays visible.

The explanatory rationale becomes optional.

Tooltips and Error Messages Live on Opposite Sides of Failure

A tooltip may help before action:

Accepted formats: PDF, DOCX, JPG.

An error message appears after mismatch:

PNG files are not accepted. Upload a PDF, DOCX or JPG file.

The tooltip is anticipatory clarification.

The error message is recovery language.

When the same error happens repeatedly, it may be evidence that the tooltip is too hidden and the instruction needs to become visible.

This gives tooltips a diagnostic role:

If important help must be rediscovered through repeated failure, the help is probably in the wrong layer.

Tooltips Should Be Short Enough to Remain Tooltips

A tooltip containing five paragraphs, three examples and a legal disclaimer has become a tiny floating article.

The container is fighting the content.

Short explanations work because the reader can absorb them without losing the main task.

Useful tooltip scale:

Sort newest first

Useful:

Confidence interval — a range showing uncertainty around an estimate

Probably too much:

A 400-word methodological explanation with links and interactive controls.

The moment the reader needs to settle in, navigate or interact, a persistent panel, details component or dialog is usually a more honest container.

Tooltips Can Accidentally Cover the Thing They Explain

A tooltip appears over a chart.

It covers the next data point.

The reader moves the pointer to see the point.

The tooltip moves.

Now another point is hidden.

This is a spatial language problem.

The explanation consumes visual territory needed for comparison.

Good tooltip design therefore considers not only the wording but where the wording appears relative to the object.

Language can clarify one thing while obscuring another.

A Tooltip Is a Form of Progressive Disclosure

Not every reader needs every explanation at once.

An expert sees an icon and continues.

A novice pauses and reveals the tooltip.

The interface therefore supports different depths of reading.

surface layer → optional clarification layer

This is progressive disclosure.

Used well, it reduces clutter without removing access to meaning.

Used badly, it turns necessary meaning into hidden knowledge that only experienced users know how to reveal.

The difference is whether the hidden layer is genuinely secondary.

Primary School: Translate the Symbol

Young learners can practise tooltip thinking without building software.

Show five familiar icons:

magnifying glass;
trash can;
heart;
bell;
paper aeroplane.

Ask students to write one tooltip for each.

Then change the context.

What does the heart mean in a health app?

What does it mean in a shopping app?

What does it mean in a social platform?

The exercise teaches that symbols need contextual translation.

Lower Secondary: Decide What Must Stay Visible

Give students a fictional interface containing:

visible labels;
tooltips;
error messages;
instructions.

Ask them to classify each piece of information:

must always be visible;
useful as optional clarification;
needed only after an error;
belongs in a larger help page.

This develops information-layer judgement rather than mere sentence editing.

Upper Secondary: Audit Hidden Knowledge

Older students can analyse an interface for invisible assumptions.

Which icons make sense only after experience?
Which critical rules are hidden behind hover?
Can keyboard users reach the same explanation?
Can touch users discover it?
Does the tooltip contain interactive content that needs another pattern?
Does the tooltip disappear too quickly?
Does it obscure nearby information?
Would making the wording visible actually improve the design?

The tooltip becomes a way to study who the interface imagines its user to be.

Ten Failure Modes of Tooltip English

Label replacement. The visible control is vague because the real name is hidden in the tooltip.
Essential-information hiding. Users must discover the tooltip to complete the task safely.
Hover-only access. Keyboard or touch users cannot reach equivalent information.
Interactive tooltip. Links and buttons appear inside a container not designed to receive focus.
Instant disappearance. The message vanishes before the reader can finish reading it.
Excessive delay. Help exists but feels unavailable.
Tooltip storm. Explanations appear constantly as the pointer moves across the interface.
Mini-article overload. Too much content is forced into a transient container.
Spatial obstruction. The tooltip covers data or controls the reader still needs to inspect.
Jargon excuse. An opaque interface is defended on the grounds that every abbreviation has a tooltip.

How to Write a Better Tooltip

Start by asking whether a tooltip is the correct layer.

Is the information essential?

Keep it visible.

Does the information require interaction?

Use a dialog, details panel or another appropriate component.

Is it brief secondary clarification?

Now a tooltip may fit.

Write from the hidden question:

What is this?
What will this do?
What does this abbreviation mean?

Answer directly.

Keep the wording small enough to read without leaving the task.

Make it available through keyboard focus as well as pointer interaction.

Allow enough time to read and dismiss it intentionally.

Then perform the disappearance test:

If this tooltip never appeared, would the essential task still be understandable?

If not, the information probably belongs somewhere more permanent.

The Deeper Idea: Good Interfaces Have Layers of Explanation

A beginner needs more English than an expert.

An expert does not want beginner explanations permanently occupying every surface.

This creates a design tension.

How do we make an interface learnable without making it permanently verbose?

The tooltip offers one answer:

Keep primary meaning visible.
Keep small secondary meaning reachable.

That is elegant when the boundary is respected.

The moment essential meaning migrates into the hidden layer, the elegance becomes exclusion.

So the tooltip teaches a larger lesson about English:

not every true sentence belongs at the same depth.

Some meaning belongs on the surface.

Some can wait quietly nearby until the reader asks for more.

Reader Checklist

Is this information genuinely secondary?
Does the visible control already have a clear label?
Can keyboard users reveal the same clarification?
Can touch users access an equivalent explanation?
Does the tooltip remain available long enough to read?
Can it be dismissed?
Does it contain interactive content that belongs in another component?
Is it short enough for a transient layer?
Does it obscure nearby content?
If the tooltip disappeared completely, would the essential task still make sense?

Research and Further Reading

W3C WAI-ARIA Authoring Practices Guide — Tooltip Pattern

Final idea: a tooltip is good when it keeps the surface clean without making the meaning disappear.