Develop example of tooltip design pattern

[mcking65]

The tooltip design pattern is at:
http://w3c.github.io/aria-practices/#tooltip

[Veyfeyken]

Any chance this will go live in the near future? I'm looking for an accessible example to point to.

[Malvoz]

@Veyfeyken

While you are waiting for the w3c developers to design a tooltip pattern, you might want to have a look at @Heydon's tooltip component.

[ZoeBijl]

Work on this is being done on CodePen. You can also view the debug page which is a lot easier to navigate with AT.

Current open issues with the implementation:

• Doesn’t detect window bounds
• Doesn’t conform to WCAG 2.1 SC 1.4.13 Content on Hover or Focus

Any help is greatly appreciated.

[krixian]

@ZoeBijl It's looking good! Is there any description on how overflowing tooltips should behave?

[weboverhauls]

Yes, looking good! Would also be great to have a tooltip example on something other than a button such as a link/anchor, text input, and possibly regular text.

[mfairchild365]

@ZoeBijl that is a great example. One question immediately comes to mind: the example uses a <button> element to trigger the tooltip. Because the tooltip is automatically displayed when the button receives both hover and focus events, activating the button element doesn't actually do anything. My hunch is that users might find a button that doesn't do anything a bit confusing and unexpected.

As indicated in #128 the presence of a button might indicate a 'dialog toolip' pattern rather than a traditional tooltip.

In any case, I think it might be worthwhile to think about what the role of the of the element that triggers the tooltip should be (when the tooltip is not attached to a form control or another element that performs a separate action, and the tooltip content is shown on touch, hover, and focus events). My gut says that no role would be sufficient, but perhaps I'm way off base.

[ZoeBijl]

@ZoeBijl It's looking good! Is there any description on how overflowing tooltips should behave?

Do you mean when there’s more text than fits ion the tooltip?

Yes, looking good! Would also be great to have a tooltip example on something other than a button such as a link/anchor, text input, and possibly regular text.

That’s a good idea! I will add that.

@ZoeBijl that is a great example. One question immediately comes to mind: the example uses a <button> element to trigger the tooltip. Because the tooltip is automatically displayed when the button receives both hover and focus events, activating the button element doesn't actually do anything. My hunch is that users might find a button that doesn't do anything a bit confusing and unexpected.

Hmm, the buttons in the example would do something if they were implemented on a page. The heart/like button is what you’d find in Twitter’s UI for example. I can trigger some kind of alert to show that it did something. Would that clarify it?

As indicated in #128 the presence of a button might indicate a 'dialog toolip' pattern rather than a traditional tooltip.

In any case, I think it might be worthwhile to think about what the role of the of the element that triggers the tooltip should be (when the tooltip is not attached to a form control or another element that performs a separate action, and the tooltip content is shown on touch, hover, and focus events). My gut says that no role would be sufficient, but perhaps I'm way off base.

While tooltips can certainly be used for other things; their main usage would still be to clarify buttons/other controls no?

From @Heydon’s article:

Literally "tips for tools", they are little bubbles of information that clarify the purpose of otherwise ambiguous controls/tools.

As for the controls not triggering anything, I can look into that. I think if I add an action to them the tooltips won’t show anymore on touch devices (which also shows how useless tooltips are for UX patterns).

[mfairchild365]

Hmm, the buttons in the example would do something if they were implemented on a page. The heart/like button is what you’d find in Twitter’s UI for example. I can trigger some kind of alert to show that it did something. Would that clarify it?

Good point, I think that would clarify it.

[carmacleod]

Great examples, @ZoeBijl !

I think you've covered all of the WCAG 2.1 SC 1.4.13 bases, because they are Dismissable, Hoverable and Persistent. Did you have something specific in mind when you wrote "Doesn’t conform to WCAG 2.1 SC 1.4.13 Content on Hover or Focus" in #127 (comment) ?

[carmacleod]

I am pretty sure that @ZoeBijl's examples pass WCAG 2.1 SC 1.4.13.
@jnurthen Can you please confirm for me?

Here's the text of the SC:

Where receiving and then removing pointer hover or keyboard focus triggers additional content to become visible and then hidden, the following are true:

• Dismissable
  A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;
• Hoverable
  If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing;
• Persistent
  The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

The example is here: https://s.codepen.io/Moiety/debug/LaPvWy
Here's my reasoning:

• Dismissable
  • hover over one of the buttons, tooltip appears. Type Escape, tooltip is dismissed.
  • tab to one of the buttons, tooltip appears. Type Escape, tooltip is dismissed.
• Hoverable
  • hover over one of the buttons, tooltip appears. Move mouse over tooltip, tooltip stays.
  • (tooltip does not timeout at all, i.e. if you hover over button and stay there, tooltip remains visible)
• Persistent
  • hover over one of the buttons, tooltip appears. Move mouse cursor out of button (and out of tooltip), tooltip is dismissed.
  • tab to one of the buttons, tooltip appears. Type tab again, tooltip is dismissed.

[carmacleod]

@ZoeBijl
Note that aria-hidden defaults to "undefined", so please use aria-hidden="true".

The other issue mentioned in yesterday's call is that the tooltip is shown immediately without any delay. May want to implement a "hover intent" pattern to ensure that a mouse user actually intended to hover.
For example, hover over github's toolbar buttons above (Bold, Italic, etc). If you move past the button, the tooltip will not display, but if you go slowly or stop on a button, then the tooltip displays.

[ZoeBijl]

That’s a good suggestion. I’ll move the code I have so far to the APG repo so we can collaborate on it more easily. My main issue is bounding box detection and I would appreciate help with that.

[maschad96]

@ZoeBijl is this something I can contribute to? I'd be happy to help if there's room for that.

[ZoeBijl]

@ZoeBijl is this something I can contribute to? I'd be happy to help if there's room for that.

I’d love some help with the bounding box stuff. I’m back on Monday and will ping you with a location of this stuff :)

[JAWS-test]

When the pattern is finished, it may also be used for WCAG. See the discussion:

• SCR39 example (SC 1.4.13 content/hover) needs improving wcag#915
• 1.4.13 Content on Hover or Focus - dismissable and persistent clarification wcag#914

[JAWS-test]

@idoros Perhaps the WCAG people have ideas on how it would be correct according to SC 1.4.13 (you could ask at https://github.com/w3c/wcag/issues)

[idoros]

@carmacleod, that's all good points, I'm trying to understand what would be a good default to start with.

I wonder if there should be different behaviors:

1. under different contexts - keep overlay under certain UI, and not under others (I don't really like this concept)
2. according to content - keep overlay for complex content that a user might be in the middle of reading
3. also should this be a developer configuration or somehow a user choice

I think that for now I would go with consistency that is easier to explain rather than a more complex behavior. Anyhow because there are 2 different input methods used together, then I assume the user has control over them and has made the choice to move the mouse over the tooltip (it's not that the tooltip just opened under the mouse), so the user can move the mouse away with a predictable outcome.

@JAWS-test - Thank you for the reference 🙏 (I have over 40 tabs with various specs and discussions on the subject, including the SC 1.4.13 somewhere), I will do some more reading and then see if there is a place to ask there as well

--- edit: opened an issue in WCAG

[carmacleod]

consistency that is easier to explain

Probably the most consistent and easiest to explain would be:

• if tooltip was opened on focus and keyboard is used to blur, close tooltip [Edit: actually, any blur, come to think of it]
• if tooltip was opened on hover and mouse is moved away, close tooltip

[a11ydoer]

@mcking65 @zcorpan Do you know why we did not have this example in the APG?

[DavidMacDonald]

Agree it would be good to come to agreement and implement in APG, unless we see a blocker.
https://s.codepen.io/Moiety/debug/LaPvWy

[ZoeBijl]

If anyone wants to collaborate on this, let me know via Twitter/email ✨. Would love to knock this out of the park in a zoom call or something ☺️.

[DavidMacDonald]

Hi @ZoeBijl
When you say collaborate, are you thinking there is more to do on the example here
https://s.codepen.io/Moiety/debug/LaPvWy
Seems OK to me...
perhaps you see something I'm missing.
I think we might be able to drop in as is, and wait for comments :)

[jnurthen]

@DavidMacDonald one issue is that the tooltip always appears at the bottom of the icon whether there is space there or not. Most tooltip implementations will render the tooltip either above or below depending on the space currently available within the viewport.

[a11ydoer]

@DavidMacDonald Here is the most recent tooltip discussion note.

[ZoeBijl]

@DavidMacDonald the thing that was missing was bounding box detection. When the control was too close to the window’s edge the tooltip would overflow outside of the window; making the text unreadable. @thezacharytaylor and I updated the component this week—it now does left and right bounding box detection and correction! We’ll see if we can do the same for top and bottom.

Should be ready fairly soon!

Updated component is at the same URL.

[ZoeBijl]

I noticed that the tooltips when viewed on iPhone and open when touched, one tooltip will close when the other is opened. However, the tool tips do not close when touched again (opened) or when touching on the surrounding background. From a usability perspective how is a touch user meant to close an open tooltip?

Good point! I’m not entirely sure how to fix it. Maybe I can check for taps outside of the button/tooltip area?

I updated the example, it will now close the tooltip when a pointerdown event is detected outside of the button.

iOS/Safari prevents the tooltip from showing again if you tap the button again. It will however work once more if you tap the other tooltip and then back to the one you closed before. I’m not sure why. But I also don’t feel like that’s necessarily a show stopping issue. Android doesn’t do this so I think it’s an iOS issue? (Fixed this with an additional event listener).

[ZoeBijl]

Development is done. The tooltip code is up on my GitHub. Feedback about their functionality and code clarity would be much appreciated! I’ll move it to a APG PR for further review after initial comments :)

[DavidMacDonald]

Awesome!
@ZoeBijl

[atoedt]

Dear ZoeBijl,
thank you very much for this. We will try and implement that pattern for our Learning Management System abnd get back with feedabck as soon as we have it. You are my hero!
Alexandra

[SukumarSV]

Pressingshift+F10as in G-docs and MS word opens the suggestion tools.

Similarly...

Tooltip: On focus we can enable the tooltip with delay, and if the user press shift+F10the pop-up will become sticky until the use ESC from it. Pressing down arrow will take the user inside the tool tip. As usual other controls will take place.

If aria-orientation requires to direct the popup direction we use that as well.

[clshortfuse]

We are rewriting our tooltips with better focus on accessibility. We have a CSS only one that is similar to the @ZoeBijl example that includes a wrapper and target (eg: .tooltip-wrapper and button.tooltip-target). It uses hover and if primary pointer is coarse (touch), there's a 1.5 second delay (as recommended by Google in their Material Design framework). Keyboard users see it immediately if they tab into an textless (icon) button.

But I'd like to share some concerns we've have with the approach since we are in the process of rebuilding.

The system doesn't work in layouts that don't have overlay:visible. Tooltips can't float over scrollbars, and if you're not careful, will appear clipped. Touch detection also has to be Javascript (unlike our previous version), because there's not enough specificity in CSS for hybrid pointer environments (eg: touchscreen PCs).

So now, we've considered tooltip should be a top-level popup (ideally HTMLPopupElement), like how we've coded combobox and menus work (include self alignment). Then, it doesn't matter what spawned it. There's also other minutia, such as, mousemove vs mouseover. Moving your cursor over a "tooltipable" element shouldn't spawn until it's still. (ie: mousemove resets counter). That would like all be folded into the same event listeners.

---

The other point is Escape to close. We do not implement this because it would be confusing for users who are focused on an icon-button within a form within a dialog. Those that could just be considered edge-cases though.

[elizabethsjudd]

We have multiple use cases in our product where we have a tooltip displaying on static content. We've added all of the functional requirements to pass SC 1.4.13 however we are getting violations from an accessibility scan that we can't have tabindex on an element without a widget role. I have yet to have any luck to find a role that passes the scan and wouldn't be confusing to users.

[JAWS-test]

@elizabethsjudd In my opinion, there is no role for it. The least confusing would be button. A button would also be appropriate if the tooltip is not opened automatically when the focus is received, but only after the button is activated.

Or tooltips are only used on elements that already have a widget role.

Alternatively, the results of the scan can simply be ignored, because the scans are not always right either. There is no WCAG rule that says that an element with tabindex must have a widget role.