Is someone willing to pull together research on tooltip nestability?

[mfreed7]

The OpenUI research page for tooltips does not include information on whether tooltips are allowed to be nested. On the WHATWG html issue for popover=hint, there's an open question about whether tooltips are most commonly allowed to be nested, or whether they're restricted to be one tooltip at a time.

Does anyone have the time to take a look into the design systems listed on the research page (or bring in more systems) and see if they allow nesting?

Additionally, do any a11y folks have input on whether nested tooltips are "ok"? I have been assuming not, but I realize (from the WHATWG conversation) that that's just an assumption that I can't justify with any data. @scottaohara @aleventhal

[brechtDR]

I'll try to kickstart this

[scottaohara]

quick notes (i'll hopefully have more later):

• research that indicates if people do it is good - but identifying if something is being done does not validate whether or not it is a good UX pattern to make 'easier' for people to achieve.
• higher level a11y/ux write ups around tooltips from @smhigley

[scottaohara]

another quick note in how the nesting of tooltips can lead to issues.

a standard tooltip is generally expected to provide an accessible description for the content that invokes it.

so <button title=blerp>edit</button> is commonly exposed as "edit, button. blerb".

Let's modify that to create a custom tooltip that produces the same output

<button aria-describedby=t>edit</button> 
<div role=tooltip id=t>blerb</div>

if we add nested tooltips to this

<button aria-describedby=t>edit</button> 
<div role=tooltip id=t>
  blerb
  <button aria-describedby=t2>term</button>
  <div role=tooltip id=t2>
     content here
     <button aria-describedby=t3>nest again</button>
     <div role=tooltip id=t3>more stuff here</div>
  </div>
</div>

the above results in the initial "edit" button being exposed as such:

edit, button. blerb term content here nest again more stuff here

Well that sucks.

But, can't we update the browser to not expose the tooltips which haven't been rendered yet?

Sure - but then when they are rendered that would fire a description change event for each nested instance. So the initial button's description would change because of the new content added into the tooltip, causing a re-announcement of that initial content and everything nested within (see previous quote) - and then any further nested tooltip would be re-announced.

but wouldn't this be covered by converting these to rich tooltips?

yes, if the association from the invoking element to the popover revised from a description to a details a11y relationship - then the previous problems go away. but new issues get introduced:

1. if an invoking element has a separate non-hint popover, and that popover is not a sibling element in the DOM - then there will already be a details relationship setup with that element. Which then means that if someone has both the "rich tooltip" and the other popover open, it'll require someone to cycle through the associated details elements to reach the popover they actually want to interact with. This becoming rather bothersome if the user just wants to get to the 'auto' popover - but because they've focused the element, the rich tooltip shows up and now they have to figure out if they went to the content they wanted to, or the other content they didn't. This is all just what needs to be considered before even getting into the nested content)
2. If we have tooltips that then contain their own nested tooltips (which can then be rich tooltips as well), this begs the question if these are really even 'tooltips' anymore, or if they're just stacking non-modal dialogs atop each other. A 'rich tooltip' may be fine as a one off if there is an important reason to have a button that has its own primary function, and the rich tooltip provides hint content also has a learn more link, or something. but if a tooltip contains buttons whose sole purpose is to invoke other tooltips, then those aren't hints anymore - those are the primary purpose of the button and then would make more sense as popover=autos.

(sorry, stopping abruptly here as i could go on for some time about this / dont' actually expect people to read all that/more than that... maybe better to acknowledge any additional questions that arise from just the above)

[keithamus]

Here is an example of nested floating UI, which would one day like to use popover=hint for both cases:

1. On GitHub.com Hover move your mouse cursor over a users avatar.
2. Move the mouse cursor over the Unfollow (or Follow) button.

[css-meeting-bot]

The Open UI Community Group just discussed Is someone willing to pull together research on tooltip nestability?.

The full IRC log of that discussion

<gregwhitworth> chair: Greg Whitworth
<gregwhitworth> q?
<hdv> brecht_dr: one of the hardest questions about this is what is a tooltip? in a lot of design systems there are popovers as well as tooltips
<hdv> brecht_dr: are the elements we're talking about the ones that show on hover or focus?
<hdv> masonf: we have popover=auto and popover=manual. The context of this question is that we're considering adding popover=hint
<hdv> masonf: and tooltips are the main driving use cases
<hdv> s/cases/case
<kizu> q+
<gregwhitworth> ack kizu
<hdv> kizu: I commented on the parent issue in WHATWG… I agree that it's hard to differentiate between popover and tooltip
<hdv> kizu: in the design system I'm working on, you can do a popover that behaves like a popover and a tooltip that behaves like popover
<hdv> kizu: so it works both ways
<hdv> kizu: we usually advice using popovers for more complex use cases, like when you have nested stuff inside
<scotto_> q+
<hdv> kizu: …it's usually popover not tooltip
<keithamus> q+
<masonf> q+
<hdv> kizu: I would like popover=hint to be a preset of defaults and still have the ability to control other aspects
<gregwhitworth> ack scotto_
<hdv> kizu: like to control various things popovers can have in common separately
<hdv> scotto_: there is one way to differentiate these things, questions about nesting aside… can we agree if a control's primary purpose is to show a popup, it can't be a tooltip?
<hdv> scotto_: in the general sense, a tooltip provides additional information to the button that opens it
<brecht_dr> q+
<hdv> scotto_: if it's a thing that provides a whole lot more it is probably a disclosure widget that happens to also be a popover
<gregwhitworth> ack keithamus
<hdv> scotto_: so a tooltip would just provide additional information to the button, like info on what the button is going to do
<hdv> keithamus: I'll second that
<hdv> keithamus: the way I see it… or we see it at GitHub… there's three rubrics to floating UIs: (1) supplementary (is the main purpose of this action to show the floating UI?) ; (2) ephemeratility (how in the way should the floating UI be?), of these there would be one at a time; (3) interactivity
<hdv> keithamus: a good sign that something is a tooltip is that it has no interactivity
<hdv> keithamus: if it does more than just that it's probably no longer a tooltip
<gregwhitworth> ack masonf
<hdv> masonf: to respond to kizu : it's key that this issue is about serving design systems for their behaviour… one thing we're talking about is what else needs to close vs needs to stay open when a popover=hint opens
<hdv> masonf: like kizu said, a lot of design systems allow you to do a lot of things, but not necessarily the right thing to do?
<hdv> masonf: in the table of all design systems that do or don't allow nesting, we should probably dig into those
<hdv> masonf: one other thing you said that was interesting… “I would like to customise the behaviours”… I'd prefer not to open up all behaviours to be allowed to be toggled, I'd rather have us bucket behaviours that make sense together
<gregwhitworth> q?
<hdv> masonf: one reason I say this is that I've found there are _a lot_ of things to decide when I implemented popover=auto
<gregwhitworth> ack brecht_dr
<hdv> brecht_dr: wanted to clarify some things: most design design systems that talk about tooltips talk about textual content only… almost always on hover and focus state… otherwise they'll call it a popover
<hdv> brecht_dr: they don't really close because another tooltip opens, they close because you're not hovering anymore
<kizu> q+
<hdv> brecht_dr: one strange behaviour that some of them have: sometimes you can click on them, they get an active state and it stays open. That's a special behaviour, I found two that have this behaviour
<gregwhitworth> ack kizu
<hdv> kizu: two other cases where we can see multiple tooltips: (1) when we keyboard focus one and hover another; (2) tooltips that are controlled, eg tooltips that are open (I think it's questionable if that's a tooltip really, or just visualyl)
<hdv> brecht_dr: one of the things I'd like to clarify… I may need some help because I don't have access to all of the design systems as they're not all public
<hdv> masonf: one thing is survey the landscape, another is what's the right thing to do
<hdv> masonf: maybe I'd open a separate issue for that
<hdv> gregwhitworth: we may already have one for popover=hitn
<hdv> s/popover=hitn/popover=hint
<hdv> masonf: I think it's worth a breakout to resolve this particular question in a more focused way
<lukew> q+

[scottaohara]

that is a great example @keithamus and i've been talking with @smhigley a lot about this since yesterday, and she's convincing me that maybe the issue here is trying to add in any extra a11y considerations beyond what was already done for popover=auto/manual... as it's those extra considerations that can be what could create some of the problems i noted in my previous comment.

hmm... i'm having a bunch of conflicting thoughts on this now.

[lukewarlow]

Here is an example of nested floating UI, which would one day like to use popover=hint for both cases:

What's the reasoning that the first one (profile card) is a hint and not auto? (Sorry if it's obvious)

[keithamus]

What's the reasoning that the first one (profile card) is a hint and not auto? (Sorry if it's obvious)

The card is supplementary info; it is not the main purpose of the link (the link takes you to a profile page). If we turned the feature off it wouldn't impact core functionality of the site. Also concretely we want the behaviour of hint in that only one hovercard should be present at a time, and it shouldn't disrupt existing auto popovers. Lastly we desire it to use the notion of "interest" because the main action is to go to the page. Based on the rubric I discussed in the meeting it strongly meets 2 of the three criteria (ephemeral, supplementary) and loosely meets the third (interactivity) - it has links inside of it but it doesn't have enough interactive content to exclude it from tooltip status.

[mfreed7]

So @brechtDR has nicely put together a starting table of behaviors, in this PR. It has some "to be investigated" rows that still need some work. Anyone up for giving that a go? The initial table should land soon, so you could put up a PR against it.

Also, given the comments above (thanks @keithamus), it seems like Github should be added as a design system in the table. With a link back to that comment, that has great context on the rationale.

[mfreed7]

Given the conversation here, I'm going to close this now. We will modify the proposal to support a stack of popover=hints.

[scottaohara]

not against the change in direction, but definitely wondering what implications this can have on the a11y mappings/ux. definitely will want to take a peak at the updated proposal when it's ready / help how i can.

[mfreed7]

not against the change in direction, but definitely wondering what implications this can have on the a11y mappings/ux. definitely will want to take a peak at the updated proposal when it's ready / help how i can.

I am curious about this also, and will welcome your input! 😄