Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Develop example of tooltip design pattern #127

Open
mcking65 opened this issue Oct 16, 2016 · 27 comments
Open

Develop example of tooltip design pattern #127

mcking65 opened this issue Oct 16, 2016 · 27 comments

Comments

@mcking65
Copy link
Contributor

@mcking65 mcking65 commented Oct 16, 2016

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

@Veyfeyken
Copy link

@Veyfeyken Veyfeyken commented Feb 5, 2018

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

@Malvoz
Copy link

@Malvoz Malvoz commented Feb 7, 2018

@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
Copy link
Contributor

@ZoeBijl ZoeBijl commented Feb 25, 2019

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:

Any help is greatly appreciated.

@krixian
Copy link

@krixian krixian commented Feb 26, 2019

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

@weboverhauls
Copy link

@weboverhauls weboverhauls commented Feb 26, 2019

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
Copy link
Contributor

@mfairchild365 mfairchild365 commented Feb 26, 2019

@MichielBijl 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
Copy link
Contributor

@ZoeBijl ZoeBijl commented Feb 28, 2019

@MichielBijl 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.

@MichielBijl 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
Copy link
Contributor

@mfairchild365 mfairchild365 commented Feb 28, 2019

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
Copy link
Contributor

@carmacleod carmacleod commented Apr 10, 2019

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
Copy link
Contributor

@carmacleod carmacleod commented May 29, 2019

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
Copy link
Contributor

@carmacleod carmacleod commented May 29, 2019

@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
Copy link
Contributor

@ZoeBijl ZoeBijl commented Jun 6, 2019

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.

@mcking65 mcking65 modified the milestones: 1.1 APG Release 4, 1.2 CR Aug 14, 2019
@mcking65 mcking65 modified the milestones: 1.2 Release 1, 1.2 Release 2 Dec 9, 2019
@maschad96
Copy link
Contributor

@maschad96 maschad96 commented Dec 30, 2019

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

@ZoeBijl
Copy link
Contributor

@ZoeBijl ZoeBijl commented Jan 4, 2020

@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
Copy link

@JAWS-test JAWS-test commented Jan 4, 2020

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

@LaurenceRLewis
Copy link

@LaurenceRLewis LaurenceRLewis commented Feb 24, 2020

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

@anevins12
Copy link
Member

@anevins12 anevins12 commented Jun 12, 2020

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.

@LaurenceRLewis
Copy link

@LaurenceRLewis LaurenceRLewis commented Jun 12, 2020

@anevins12 I admit I did not consider panning outside the tooltip area. I have removed the link until I run more testing.

@anevins12
Copy link
Member

@anevins12 anevins12 commented Jun 15, 2020

@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!

@LaurenceRLewis
Copy link

@LaurenceRLewis LaurenceRLewis commented Jun 15, 2020

@anevins12 no worries, I ask questions often because I misinterpret a Success Criterion.

@idoros
Copy link

@idoros idoros commented Jul 6, 2020

  • 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?

@StommePoes
Copy link

@StommePoes StommePoes commented Jul 6, 2020

^ what do 80+% of users expect?

should they be trained to expect otherwise?

@idoros
Copy link

@idoros idoros commented Jul 6, 2020

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.

@carmacleod
Copy link
Contributor

@carmacleod carmacleod commented Jul 6, 2020

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

@JAWS-test
Copy link

@JAWS-test JAWS-test commented Jul 6, 2020

@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
Copy link

@idoros idoros commented Jul 6, 2020

@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
Copy link
Contributor

@carmacleod carmacleod commented Jul 6, 2020

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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet