Tooltip pattern

[mjbp]

Accessible tooltip pattern

Criteria

• The tooltip typically becomes visible in response to a mouse hover, or after the owning element receives keyboard focus
• authors should display the tooltip after a short delay (wai-aria suggests 1-5 seconds)
• elements with the role tooltip are referenced through the use of aria-describedby before or at the time the tooltip is displayed
• A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus (e.g. escape key)
• If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
• The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

Refs
https://www.w3.org/TR/wai-aria-1.1/#tooltip
https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html
https://primer.style/view-components/components/alpha/tooltip
GoogleChrome/web.dev#8959

[sarah-storm]

Hello!

I've spent a bit of time today looking at this pattern and have an example of it running in a branch which matches the guidelines. I've found a few issues with it though, and wondered if it's worth continuing.

I've been looking at this suggested implementation and running a version of it as one of our patterns:

https://www.w3.org/WAI/WCAG21/Techniques/client-side-script/SCR39

My WIP branch is here:

https://github.com/stormid/ui-patterns/tree/feature/52-tooltip

First and biggest issue is the lack of touch support for devices. The critera from the w3c doesn't expect this, but if we don't have it - does that make this pattern redundant? Tooltips have dropped out of favour almost completely since touch devices came along, and there's a big push for everyone to rethink their UX if they find they have to fall back on them.

If there are instances that we don't need to consider touch devices, the pattern works - but the requirement to have a delay causes issues. If the tooltip panel needs to sit away from its trigger so as not to obscure it, then there is inevitebly at least a pixel gap between the element and its trigger. The delay of the element appearing causes a flicker at 100ms and breaks the critera of persistance at 1000ms. The W3C's own example doesn't implement a delay at all, so it's not obvious that's the case.

I did have to put in an additional script to pass keydown events through to the embedded iframe, but that's more just a requirement from the way our docs are done.

Any thoughts on the branch and the above would be appreciated - very much not finished, tested, documented.. I just wanted to get other opinions before taking it to completion!

cc @mjbp @Nick-StormID @catvine-stormid

[sarah-storm]

p.s. I did also have a look around to see if there was a new and shiney way of doing tooltips for touch, but they all still seem to involve taking the touchstart/end events and doing something like sniffing out a double tap or a long press. Both these feel like they would get in the way of OS functionality (certainly on iOS a long tap on a link/button has a context menu).

[Nick-StormID]

@sarah-storm as you say, the implementation you have is not finished - so critique seems out of place (but the pre-open delay feels really wrong, disconnecting the user action from the effect). More pertinent is your questioning of the use of this pattern at all.

It feels like the pattern doesn't have clear consensus over use (W3C and Git Hub threads), and the issues you raise regarding use with touch devices make me lean towards thinking it is a pattern we should be recommending against.

[mjbp]

@sarah-storm @Nick-StormID I raised this when the product team on a specific project were pushing for tooltips and I wanted to find the least worse implementation. Eventually I successfully pushed back and we didn't do tooltips.

I agree that we can park this for now but it serves as very useful research and a reference point when they arise again in designs.