Delay before the tooltip shows up

Quick answer: wait about 300 to 500 milliseconds after the pointer stops on the trigger, then show the tooltip immediately. Once one tooltip is open, show the next one with no delay as the user moves along a toolbar. Keep it open while the pointer moves onto it, and close it on Escape.

UX designers have introduced the delay before a tooltip shows up to make sure that the user actually wants to see the tooltip. The 300-500 millisecond pause is to ensure user intent is to see what is behind the tooltip and not mousing by on their way to something else. Today, we will discuss if this is a good UX practice.

Generally, yes. But not always. We believe user research should answer this question.

First, let’s take a look at the reasons for implementing the delay:

1. Reduce cognitive load by ensuring that the user wants to see the tooltip before it is displayed
2. Tooltips can be visually distracting, so by delaying their appearance, you’re giving the user a better opportunity to focus on the task at hand

Both of these reasons make sense, but do they actually hold up in practice?

There is some evidence to suggest that delaying the appearance of tooltips does not actually reduce cognitive load. Similarly, there is a belief that delaying the appearance of tooltips can be visually distracting.

So, what do we make of all this?

It seems that there is no clear consensus on whether or not delaying the appearance of tooltips is a good UX practice. It depends on the use case. There is a list of steps for the Neilson Norman Group that we can apply if the case requires a delay:

1. Mouse cursor enters target area: display visual feedback within 0.1 seconds.
2. Wait 0.3–0.5 seconds.
3. If the cursor remains stopped within the target area, display corresponding hidden content within 0.1 seconds.
4. Keep displaying the exposed content element until the cursor has left the triggering target area or the exposed content for longer than 0.5 seconds.

If you are considering implementing a delay before tooltip appearances, it is important to test it out with your own users to see if it is effective. If you find that the delay is causing a decrease in performance or distraction, you may want to consider reversing the delay or finding another way to reduce the cognitive load or visual distraction.

What design systems use

The defaults in popular component libraries sit at either end of that range:

Library	Delay before showing	Notes
Atlassian Design System	300ms	The same delay is used before hiding
Radix UI	700ms	After one tooltip closes, others open instantly for the next 300ms (skipDelayDuration)

That "skip delay" is the detail worth copying. The first tooltip needs a delay to confirm intent. Once someone is clearly scanning a row of icon buttons for the right one, making them wait again at each icon is just friction.

Hide delay and accessibility

The delay on the way out matters as much as the one on the way in. WCAG 2.2 success criterion 1.4.13 Content on Hover or Focus requires hover and focus content to be:

• Dismissible without moving the pointer or focus, usually with the Escape key.
• Hoverable, so the pointer can move onto the tooltip without it vanishing. This is important for people using screen magnifiers.
• Persistent until the user moves away, dismisses it, or it stops being relevant.

A short hide delay, like the 0.5 seconds in the NN/g steps above, makes the hoverable rule much easier to meet. Also show the tooltip when the trigger receives keyboard focus; there is no accidental "mousing past" with a keyboard, so no delay is needed.

What about touch screens?

There is no hover on a phone, so there is nothing to delay. Tooltips on touch devices usually appear on long press or on tap of a separate info icon. We cover the options in tooltips on mobile websites and alternatives to hover on touchscreens.