aria-practices
aria-practices copied to clipboard
w3c
Develop example of tooltip design pattern
The tooltip design pattern is at: http://w3c.github.io/aria-practices/#tooltip
Any chance this will go live in the near future? I'm looking for an accessible example to point to.
@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.
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:
- [x] Doesn’t detect window bounds
- [x] Doesn’t conform to WCAG 2.1 SC 1.4.13 Content on Hover or Focus
Any help is greatly appreciated.
@ZoeBijl It's looking good! Is there any description on how overflowing tooltips should behave?
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.
@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 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).
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.
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 https://github.com/w3c/aria-practices/issues/127#issuecomment-467152945 ?
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.
@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.
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.
@ZoeBijl is this something I can contribute to? I'd be happy to help if there's room for that.
@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 :)
When the pattern is finished, it may also be used for WCAG. See the discussion:
- https://github.com/w3c/wcag/issues/915
- https://github.com/w3c/wcag/issues/914
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?
I may be missing something, but, the tooltips do not seem to work when running VoiceOver on IOS (iPhone).
Thanks
https://s.codepen.io/Moiety/debug/LaPvWy
Updated to include a reference to the excellent article ‘ Tooltips in the time of WCAG’ (2.1 August 17, 2019) by Sarah Higley https://sarahmhigley.com/writing/tooltips-in-wcag-21
I may be misunderstanding @LaurenceRLewis , but does Scott's examples hinder someone using a screen magnifier that could be panning over left, right, down or up around the tooltip to see it all? By panning around the tooltip, not necessarily on the tooltip itself, the tooltip can disappear.
@anevins12 I admit I did not consider panning outside the tooltip area. I have removed the link until I run more testing.
@LaurenceRLewis I think that I had a slight misunderstanding in the WCAG On Hover or Focus criterion in that I misread this bit:
then the pointer can be moved over the additional content without the additional content disappearing;
It doesn't say the pointer can be moved around the additional content. The criterion is specific to moving the hover over the additional content.
Now that I think of it clearer, we see that behaviour all the time in dropdown navigation menus. With the pattern so common I think it would be fine to have Scott's examples recommended here.
Sorry for the confusion!
@anevins12 no worries, I ask questions often because I misinterpret a Success Criterion.
- 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, I'm sorry if I missed something, but what should be the cross behavior between focus and hover.
case 1: focus a button -> tooltip appears -> move mouse over the tooltip or button -> tab to blur button.
should the mouse keep the tooltip alive until it moves out?
case 2: focus a button -> tooltip appears -> move mouse over and then out.
should the tooltip disappear?
^ what do 80+% of users expect?
should they be trained to expect otherwise?
I can't say for 80% of users, but my intuition is that no matter how a tooltip opened, holding the mouse pointer on it is like another focus point that should keep the tooltip content persistent even when the actual focus is moved a away.
Given this thinking, when the tooltip is invoked by the focus, a mouse might dismiss it by waving it away like esc would.
@idoros
what should be the cross behavior between focus and hover.
Good question. I don't know the answer. Your suggestions sound reasonable, but as @StommePoes said, you might want to do some user testing to see which behaviors users find the most intuitive. I'm not so sure about case 1 in a toolbar, though. If I shift+tab to the markdown toolbar for this github comment editor (H, B, I, etc) and use left/right arrow keys to move through the toolitems, I think I would prefer that the previous tooltip closes when I type arrow to focus the next toolitem (no matter where the mouse is), because I don't want to see two tooltips - I just want to see the next one. For case 2, if a user is using a mouse-controlled magnifier to read the previous tooltip and then they type tab, I think they might want the tooltip to close so that they can move on to the next focused element. I'm only guessing though.
@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)
@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:
- under different contexts - keep overlay under certain UI, and not under others (I don't really like this concept)
- according to content - keep overlay for complex content that a user might be in the middle of reading
- 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
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
@mcking65 @zcorpan Do you know why we did not have this example in the APG?
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
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 ☺️.