[Meta][EuiTooltip] Flexibility, accessibility & guidelines

[cchaos]

Flexibility

Currently, adding EuiTooltip can be a bit of a pain because you have to wrap your component with the EuiTooltip component, which creates a wrapping DOM element, which may not display as you need so you have to pass an anchorClassName to override the display...

A couple of ways we can make adding tooltips easier and more flexible:

• Allow most components to simply accept a tooltipContent prop that will automatically add the necessary refs to the component to position the tooltip against without having to create a wrapper. (Related: [Discuss] Allow buttons to accept tooltip props #2027)
• EuiTooltip will still be available as a component as it exists today with some extra allowances like wrapping around a string in which the tooltip's anchor wrapper would become focusable. (Related: Allow strings for EuiToolTip children #2292)
• Implement an extra long delay and probably smaller sized tooltip to replace browser title tooltips. This would help us to add our own tooltips to truncated components without relying on title which has questionable a11y support. (Related: Always set a title attribute when truncating text via CSS #1923, Discuss and document guidelines for using EuiTooltip vs the title property #3588, Add an EuiTextTruncate component #4085)
• For icons or other elements that have meaning without text (but the textual context is helpful) and where we usually add aria-label, we could try to simplify this combination of aria-label and title with a tooltip. So that the screenreaders appropriately give meaning to the icon while their textual description can also be given for mouse users. (Related: [Discuss] If aria-labels are supplied, add them to the title attribute as well? #2021)

Accessibility

Following watching this presentation on the accessibility and overall useful "tips" for tooltips. My takeaways for EuiTooltip (understanding that tooltips in EUI are here to stay 😉 ):

✅ On focus
✅ No dismiss on timeout
❌ Touch/eye control devices
❌ Dismiss without moving “cursor”
❌ Tooltip content is hoverable

• Could create a toggle-able version (clickable anchor though couldn’t have any other function).
• And/or just simply supply a close button close to the triggering element. We’d have to implement the triangle path to the tooltip. Add a floating close button to all "popovers" #3024
• Even though she said ESC may not be ideal, it may be a good solution in addition to a close button

Guidelines (added to docs in #5066)

Some additional bits we should add to doc guidelines for usage:

• Keep it short
• Keep in mind the purpose: naming or describing
• Keep it non-essential

[myasonik]

Related #3024

---

I'm broadly +1 on all the ideas. Each of those would improve our tooltips.

To add one more thing we could do, maybe just as usage guidelines in the docs right now, is to remind consumers that any and all content that's in the tooltip looses all structure so anything other than a naked string is probably better suited for something else (e.g., headings are lost, actions are practically unreachable).

[cchaos]

Here's a start on some good do's and don'ts:

Don't: Put interactable content in a tooltip
Do: Use a popover

Don't: Hide important validation information behind a tooltip
Do: Use inline help text

Don't: Put formatted text in the tooltip
Do: Unless it can have the same meaning if read as plain text

[cchaos]

As a side note, some of the more a11y focused efforts here could also be pushed onto EuiPopover as well.

[cee-chen]

Closing this as not planned due to the age of the issue and lack of owner.