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

[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.

[phoenisx]

Hi Folks!

Are tooltips not supposed to be clickable? I was working with some component libraries and (all of them which I worked with) do not make tooltip visible on click.
This is the same behaviour mentioned in https://www.w3.org/WAI/ARIA/apg/patterns/tooltip/ as well.

But if that's the case, how will someone be able to open a tooltip on Mobile devices, with touch only interactions?

[clshortfuse]

@phoenisx They shouldn't be interactive. Interactive one would be "toggletips" which are something else more aligned with popups. I know Android/Material Design shows tooltips after holding a button down for a short period of time.

[aleventhal]

Would be great to an example of rich tooltips using ARIA so that we can ensure they work with Chrome

[aleventhal]

Actually, any current page that works like a tooltip, even if it's not an official example. @mcking65 @keithamus anything on Facebook or GitHub that we can use?

[clshortfuse]

@aleventhal I have this setup, though not sure why it comes up as aria-hidden

https://clshortfuse.github.io/materialdesignweb/components/buttons.html

Edit: I haven't added automated ARIA testing for mdw-tooltip specifically, but can take a look.

[kpjfairns]

Can screenreaders automatically prioritise the tooltip, so that the blind can be guided on where these tooltips even are, let alone what they say?

They may not even be able to read the tooltip unless integration with screenreaders is prioritised to some extent

This would probably mean a need to develop more from the screenreader perspective, being able to inject a tooltip as a secondary audio process will allow the text being read to continue, while also allowing the exploration of the webpage through the tab index, which should allow for tooltip enabled elements to be in focus independently of the rest of the text, even if the tooltip itself isn't able to be focused on through the tab index, which is a different problem in and of itself: Because the tooltip itself never receives focus and is not in the tabbing order, a tooltip can not contain interactive elements like links, inputs, or buttons.

It continuing to read the background text without context switching can sometimes be a problem for alerts and popup|model overlays, taking that into consideration may be helpful