Tooltips + Icons

[ghostling]

Hi 👋 we're looking to replace these icon / tooltip with Paste components.

In the Tooltip docs, I see:

A tooltip must be placed on a focusable element, such as an anchor or button.
Do not place tooltips on non-focusable elements, like an icon. Wrap them in a focusable element and place the tooltip on that.

Noticing a few problems with the suggested approach:

1. Icon is dark blue as it is nested in an Anchor. (not very visible in the screenshot as it's being hovered on)
2. Icon is clickable. -- For this, is doing <Anchor href="javascript:;"><InformationIcon /></Anchor> an acceptable workaround? It is still clickable and visually looks strange.
3. If you hover long enough it looks like there is two tooltips:

To fix 1 & 2, is this an appropriate solution? If so, can this be added to the docs instead of the current example?

            <Tooltip text="hi">
              <Box as="span" tabIndex={0}>
                <InformationIcon decorative={false} title={"Open Tooltip"} />
              </Box>
            </Tooltip>

Still has problem 3, but we could probably live with that...

Tangential question: By default it doesn't look like the background color of the Tooltip matches what I see in the docs? (Expect: color-background-body-inverse)

[TheSisb]

Hi @ghostling,

Icon is dark blue as it is nested in an Anchor. (not very visible in the screenshot as it's being hovered on)

You can pass a color prop to icons to change their color.
<Icon color="colorText" />

Icon is clickable. -- For this, is doing an acceptable workaround? It is still clickable and visually looks strange.

The reason why we request adding tooltip icons inside a focuseable element is so that screen reader users can tab through the page and get the same content as mouse & sighted users. For more details on this subject, you can check out this article: https://inclusive-components.design/tooltips-toggletips/

If you hover long enough it looks like there is two tooltips:

You can pass decorative={true} to the icon to remove its default interaction since the tooltip covers that. cc @SiTaggart to validate this is okay as the resident a11y expert.

To fix 1 & 2, is this an appropriate solution? If so, can this be added to the docs instead of the current example?

That's pretty clever. I'm not 100% sure on this approach. CC @SiTaggart again.

By default it doesn't look like the background color of the Tooltip matches what I see in the docs? (Expect: color-background-body-inverse)

Are you on the latest version of Paste packages?

[ghostling]

🤦‍♀️ Note to self to always update Paste packages... that fixed the background color 😄

[SiTaggart]

In terms of focusable divs or spans as the triggers of tooltips I would strongly recommend against it. When we refer to "focusable elements" we are talking about natively focusable HTML elements, and the reason being is that it communicates interactivity to users of assistive technology. A focusable div or span has no means of communicating it is interactive.

With that in mind, if you're tooltip doesn't navigate anywhere I would suggest using a button as the trigger. Setting size and variant to reset should get you the same visual treatment.

<Tooltip text="hi">
  <Button size="reset" variant="reset">
    <InformationIcon decorative={false} title={"Open Tooltip"} />
  </Button>
</Tooltip>

This is very similar to the "Inclusive toggletips" section in the article that @TheSisb posted.

To remove the title from the Icon, setting decorative={true} as suggested by @TheSisb is fine, but you will be required to add an aria-label to the Button itself, otherwise the button will have no text content to communicate what it does. <Button aria-label="more info" /> is an example.

But that leads to the real underlying problem of how to deal with this "information tips" that are so highly used across console.

The first thing to mention is that the ideal transition path from old to new might not actually be the direct translation of what we currently have in console. The Paste suggested treatment that hasn't been explored might be to not use a tooltip at all in this instance. It might actually be a better design to show the supplementary text directly underneath the item, rather than hide it away.

The second thing to mention is that we don't yet have clear guidance on, if you absolutely must use an information tip, how to actually do that appropriately going forward. My hunch is, the suggestion I will make is to follow the "Inclusive toggletip" guide on that article https://inclusive-components.design/tooltips-toggletips/. This will mean we use a Popover, with a button surrounding the i icon. You click the i icon, the Popover shows.

[ghostling]

Thanks for the detailed reply! The Button tip is very helpful and suits our needs. I agree that we should find a different path forward to replace the use of information tooltips. My current focus is migrating an existing page as is, so that is out of scope, but will be sure to add that feedback when we get around to redesigning this page.