[EuiTooltip] [EuiContextMenu] Allowing tooltips to be hoverable

[lucasfcosta]

Summary

This is a feature request for making tooltips hoverable. Doing so would allow us to have links in tooltips.

Currently, we cannot have links to any help materials in tooltips because they will disappear as soon as users move their mouse out of the target element towards the tooltip.

Please notice that this behaviour could also be available for tooltips within an EuiContextMenu for the sake of completeness.

I also considered filling this as a bug, as tooltips are actually allowed to be hoverable as per the examples in these guidelines from the Nielsen Norman Group.

Real-world example of how this could be useful

We recently added tooltips to the Uptime app which inform users about the need for permissions (as you can see in elastic/kibana#120379).

@liciavale recommended that we add a link to our documentation so that users can fix the problem described in the tooltip. That link, however, can't be clicked, as the tooltip will disappear when users move the mouse out of the target element towards the tooltip, as you can see in the gif below (please ignore the colour of the link, we could just set its colour to ghost):

[elizabetdev]

Thanks, @lucasfcosta for opening this issue.

We've been working on establishing guidelines for in-product help. See #2677.

I also considered filling this as a bug, as tooltips are actually allowed to be hoverable

We want to ensure consistency across our products. Making the tooltip hoverable might be one solution but first, we need to see if there are other patterns that we can introduce.

[chandlerprall]

Adding the ability to hover over the tooltip without dismissing it is required by WCAG 2.1 Section 1.4.13,

Hoverable
If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;

We could still enforce or recommend not including interactive content in the tooltips through code and/or the guidelines @miukimiu linked. If we do allow interactive content, we would likely want to wrap it with a focus trap to enable keyboard access, as we use React portals to place tooltip content at the end of the DOM.

Last, if we want to look at adding full WCAG 2.1 support, we would need to also address

Dismissible
A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;

[cchaos]

Related #4040

[1Copenut]

I agree with @chandlerprall and recommend we avoid adding links to tooltips. The NNG example in the original description doesn't make allowances for keyboard navigation, which excludes assistive tech users and those who navigate by non-mouse devices. Tooltips are great for disambiguating acronyms or complex instructions. If there are links to longer docs or related actions, I feel it'd be better to have those on the page or available in the menu without having to discover them in a tooltip.

[spong]

Saw this in passing and just wanted to add another data point from the Security Solution side of things. We recently had the need for adding a docs link to a tooltip as well and ended up using and EuiPopover to accommodate instead. Not the best for consistency, but it works. See elastic/kibana#114023 for more details.

Specifically, our need was to provide more details on table columns:

Query Time:

Last Gap:

[github-actions]

👋 Hey there. This issue hasn't had any activity for 180 days. We'll automatically close it if that trend continues for another week. If you feel this issue is still valid and needs attention please let us know with a comment.

[github-actions]

❌ We're automatically closing this issue due to lack of activity. Please comment if you feel this was done in error.