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