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

[Button] - icon only button, two tooltips visible and overlapping each other #4560

Closed
tomkdgun opened this issue Nov 5, 2019 · 10 comments · Fixed by #8022
Closed

[Button] - icon only button, two tooltips visible and overlapping each other #4560

tomkdgun opened this issue Nov 5, 2019 · 10 comments · Fixed by #8022

Comments

@tomkdgun
Copy link

tomkdgun commented Nov 5, 2019

[Button] - icon only button, two tooltips visible and overlapping each other.

Icon only buttons are very common to be used on toolbars, or as buttons inside DataTable rows e.g. edit/delete actions.

Currently last clicked button icon only button has focus, and tooltip is visible on focus.
When I hover over another icon button, another tooltip is also visible, so both are present and overlapping each other:

image

Steps to recreate:

  1. Create two icon only buttons next to each other.
  2. Click on button one - button focused tooltip visible,
    or focus button using Tab
  3. Hover over button two - both tooltips visible and in most cases overlaps since buttons are 48px size.

I think tooltip for focused button should disappear just after someone will hover over different icon only button. Other option is to remove the rule to show tooltip for focused icon only button.
Regarding accessibility, use of aria-label should be sufficient. I think screen readers will also correctly handle disabled button state, without a need of adding aria-disabled.

Set of icon only buttons are common in toolbars (just different icons):
image

What package(s) are you using?

"carbon-components": "10.7.3",
"carbon-components-react": "7.7.3",
"carbon-icons": "7.0.7",
@tomkdgun
Copy link
Author

tomkdgun commented Nov 7, 2019

Note: We need the fix for this issue quickly, for IBM SPSS Statistics

@janhassel
Copy link
Member

Any updates on this one?

@emyarod
Copy link
Member

emyarod commented Jan 23, 2020

visible tooltip on hover and focus is an accessbility requirement, so I don't know if we can change that behavior (related #5069)

the pattern for showing/hiding tooltips when multiple tooltips are present is still a WIP (refs w3c/aria-practices#127 w3c/wcag#914 w3c/wcag#915)

currently there is a PR open for dismissing all tooltips via Esc which is a stopgap solution until the pattern is fleshed out (#5147)

@janhassel
Copy link
Member

Thank you for detailed update, @emyarod. Really appreciate it! 👏

@tw15egan
Copy link
Member

I'm going to mark this as blocked until the w3c delivers a solution to this pattern

@asudoh
Copy link
Contributor

asudoh commented Mar 11, 2020

A workaround @emyarod told me is changing the alignment to avoid overlapping.

@tomkdgun
Copy link
Author

@asudoh Since we have many buttons like this next to each other (toolbar) near top left or top right edge of window, I don't have option to change alignment. When I change some to be left or right, tooltip will cover other buttons and interaction with them will be spoiled, top can't be used (top edge of screen), left together with right also, since tooltip will overflow window window edge, and wan't be visible.

@emyarod
Copy link
Member

emyarod commented Mar 11, 2020

the w3c issues referenced above have not been resolved yet, but #5147 added Esc key support for dismissing any open tooltips which may be a workaround. if that is not sufficient, then we will need some design guidance on what to do in this situation as there are multiple ways to trigger multiple tooltips on a page

@jhpedemonte
Copy link

I don't think Esc is a good way to dismiss focused tooltips. First, it's not easily discoverable; secondly, there seem to be a ton of issues around it (e.g. tooltip within a modal dialog? See linked w3c issues above).

I think this is due to "competing" implementations for keyboard- vs mouse-based navigation. For keyboard nav, we use focus to show the tooltip; for mouse nav, hover. However, when clicking on an icon-only button with the mouse, this also activates the focus handler.

One possible fix for this would be to ensure that only a single icon-only button (or any other widget?) can have an "active" visible tooltip. This could be accomplished by surrounding such buttons in a ButtonGroup parent component, whose only purpose would be to detect mouseover events and remove any existing focus.

This could even be extended to work on the entire page -- make it implicit in the tooltip impl, so that developers don't need to worry about adding a "button group".

I haven't tried to implement this and there may be some gotchas I haven't thought about. But it seems that having multiple tooltips visible at the same time isn't necessary for mouse-based navigation.

@carmacleod
Copy link
Contributor

Please unblock this. Don't wait for w3c, because you will be waiting a very long time. :)

In the meantime, having 2 tooltips visible at the same time is a bug that should be fixed.

I think it can be fixed and still meet WCAG 2.1 1.4.13 Content on hover or focus by doing the following:

  • if the tooltip is initially triggered by focus, then it should be dismissed when focus is removed (or if a different tooltip is triggered by hover)
  • if the tooltip is initially triggered by hover, then it should be dismissed when hover is removed (even if the button still has focus)

See also: #7040

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
10 participants