Toggletip vs. Tooltip Docs Guidance Update

[laurenmrice]

Acceptance criteria

• We need to do some research on how we want to structure Tooltip and its variants versus Toggletip.
• There have been discussions about removing the "Standard" Tooltip variant, but also concern if people actually need that use case still and use it in code. We need to first see if we can find valid use cases for this before making the decision of removing it.
  • Ref: a11y Tooltip ombnibus issue
  • Ref: a11y Toggletip omnibus issue
• There were also discussions from a11y about only using the information icon in Toggletips and not at all in Standard tooltips, is this valid or are there instances where using the information icon could be used in Tooltips?

Tasks

Preview Give feedback

1. Research and find use cases of toggletips and different tooltip variants
2. Playback findings to design and a11y team
3. Take feedback from playback and align on one direction to move forward with for Toggletip and Tooltip variants
4. Update or create issues to make any changes to toggletip and tooltip, link them here?
5. Will there be kit work? TBD
6. Will there be dev work? TBD

[sstrubberg]

@mattrosno can we get metrics on Tooltip usage? variants of tooltip & toggletip.

[mbgower]

@laurenmrice I found another place where the guidance must be updated in https://carbondesignsystem.com/patterns/forms-pattern/#offering-help

I believe that pretty much everything covered under "Tooltip" here is actually for toggletip. Some of the info under the following Helper text subsection should also be reviewed.

[mbgower]

Here's another great implemented example of how the two are being confused.
https://react.carbondesignsystem.com/?path=/story/components-formlabel--with-tooltip

Two identical looking "i" buttons with completely different behaviour (for mouse, keyboard and touch).

As previously argued, the first, using a tooltip, should not exist. A tooltip's primary (only?) purpose is to expose the name of an icon-only button --a button that already takes focus in order to allow a user to perform its primary role. This first i button does nothing on click, which makes no sense.

In addition, it is also bewildering to a touch user, who is going to click on this first i button and nothing is going to happen.

The second i button works sensibly as a toggletip, operable and understandable to all modalities.

Just changing the border of the i button -- which I think is what is proposed here? -- only partially resolves this basic conflation of two interactions.

[aagonzales]

Okay, this topic was brought up again today. I think we need to refine our definitions of tooltip and toggle tip. Most of our docs don't align with @mbgower's proposal, which states that the info icon only triggers a toggle-tip. Could different icons other than an info or help icon trigger a tooltip? Here is an example we have in docs.

Because I'm kind of wondering what's the purpose of the default tooltip component if the icon-button tooltip and definition tooltip exist as separate components? Is it just a primitive now? And if so how is it different than popover?

Can an icon-button tooltip contain more than just the icon label name? Can it container a longer description?

[aagonzales]

And then there's the ultimate question: can a toggletip use a tooltip? Like this Help Button. Tooltip is the prompt so the user knows to click on it.

(This is the same problem that also came up with the AI Labe and wither it should have a tooltip even though it already triggers a popover).

[mbgower]

Could different icons other than an info or help icon trigger a tooltip?

@aagonzales Yes, any icon button can trigger a tooltip. For that matter, any target can trigger a tooltip. In fact, the title property, which causes the browser tooltip (as opposed to Carbon's) can be put on anything, whether it is operable or not. This last, however, immediately causes a challenge for a keyboard user (who can never reach something that does not get focus). So that info would need to be supplied in some other way.

can a toggletip use a tooltip?

Yes, the target for the toggletip (the i icon) can have a tooltip -- just like any other control -- and also trigger a toggletip content area.

[mbgower]

At the risk of muddying the waters, there are examples of a few overlays in the current github UI worth mentioning, since they help illustrate both trigger considerations as well as questions about the nature of tooltips.

I think when we talk about tooltips, we're talking about a behaviour more than the nature of the information, but there does seem to me to also be an informational divide.

What do I mean? Behaviourly, tooltips appear on hover as well as on focus (if they're accessible). It is in some ways an 'unintentional' user action (in that the tooltip appears not because the user necessarily intended to show it, but because their input device encountered a trigger). Informationally, I think we'd get common agreement that a text-based piece of information resulting from hover is a tooltip. But what if a megamenu appears when I hover over a link in the Header UI Shell (a common behaviour less than a decade ago)? I wouldn't call that a tooltip. I'd call that a poorly implemented component. But there are forms of hover-triggered content which I'd still consider a tooltip, even though it is no longer strictly text.

Some examples on this page...

First, if you hover over the tag that says "Member" in the upper right corner of this post, you'll see that it has a tooltip that says "This user is a member of the carbon-design-system organization." That is not operable by keyboard (or touch) because there is no actual interaction there, it's just a static tag. I think everyone would agree that this presents as a tooltip (both its styling and the fact it is text-based). It's not giving the name of the tag, since that it is already labelled "Member". So this text is arguably description -- an elaboration of something one can extract from the context. As such, although this tooltip cannot be operated by keyboard, I'd consider it a pretty "lite" failure.

A different form of what could be called 'tooltip' exists on this page if you hover over the link below Lauren's prior post, which reads "Toggletip resolve a11y concerns #4358".

Even though I cannot make this information appear with a keyboard, I can activate the page and get that information. So IMO, this is allowable in 2.1. 1 Keyboard, because there is a keyboard method of getting the same information.

Would I call this preview a tooltip? Probably. It's a descriptive tooltip rather than a name. But it illustrates that what is shown is less important in how I'm defining it than how it is triggered. At some point, we're going to run into questions of how the richer content potentially revealed on hover/focus can be property surfaced to ATs, and that's when calling them all 'tooltips' might become problematic. Just wanted to flag that for future consideration.