The problem with tooltips and what to do instead

In 2006 I coded up my very first tooltip.

Tooltips are messages that appear when the user hovers over part of an interface—usually an icon—to explain how certain things work or what they mean.

Despite some of the coding challenges, I thought tooltips were a cool way to declutter the UI.

But what I didn’t do was think about how they impact UX.

How are keyboard or touch screen users meant to operate them? What if the user wants to read the tooltip at the same time as filling out a text input?

Turns out there are 6 good reasons to avoid this pattern.

Here I’ll explain what they are and what to do instead if you want to give users a good experience.

1. They’re hard to spot

Some users won’t notice a tooltip which means there’s a high risk they’ll never see the content it contains.

Tooltips are hard to spot

2. They require effort

Let’s say users need additional information to help them satisfy a password field with complex rules. Making users reveal the content first is an unnecessary burden.

Revealing content requires effort

3. They obscure the screen

Tooltips are shown on top of the screen blocking some of the interface.

This means you can’t read the tooltip and operate the rest of the screen at the same time.

Part of the screen is obscured

Users have to work hard to remember the hint, or switch between 2 modes of operation repeatedly.

4. They could be cropped in small screens

As tooltips are overlaid, there’s a chance they’ll be cropped by smaller viewports.

Tooltips could be cropped

5. They don’t work well with speech recognition

Tooltips that consist of icons need an accessible label. But even if you have one, voice users have to interpret what they see and guess what it is.

Icons are hard to target with speech recognition software

Imagine a bell icon. It’s not clear whether users should say ‘Click bell’, ‘Click notifications’ or something else entirely in order to activate it.

6. Revealing content on hover is inaccessible

Firstly, you need to use a mouse or other pointing device to use a tooltip which excludes keyboard and touch screen users.

Secondly, hovering is not always an intention to activate a control. The user might move the cursor over a tooltip which accidentally activates it.

Thirdly, it requires fine motor skills to operate. Users have to move their mouse accurately over the hit area and hold it steady to avoid accidentally hiding it.

Fourthly, it’s not possible for screen magnifier users to move their field of view without hiding the tooltip.

Finally, users can’t select or interact with the content within the tooltip.

You could provide a comparable experience for keyboard users by showing the tooltip on focus. But this is unconventional and still excludes touch screen users.

What to do instead

1. Do the hard work so users don’t have to

Having content just to help users understand your interface is a sign of bad design.

If you’re using an icon to convey meaning, use text instead, or use icons and text together.

Top: just an icon (bad). Middle: just text (good). Bottom: text and icon (good).

If you’ve got one complex question, can you make it simpler by asking several shorter questions?

Either way, do the hard work to make it simple.

2. Just show the extra content

If you really do need to provide users with clarification just show the content.

Top: content in a tooltip (bad). Bottom: content inline (good)

Give users what they need when they need it.

3. Use a better pattern for toggling content

If (1) and (2) don’t work, use an inline toggle component.

A toggle component

This is better because it:

  • doesn’t rely on iconography alone
  • won’t be cropped by the viewport
  • doesn’t obscure content
  • is activated on click which works well in all contexts

Thanks to Amy Hupe for editing this.