Tooltip vertical position is too high, causing loss of hover state

[JJJ]

Describe the bug
Because tooltips do not disappear when they are hovered over, and because they now overlap the thing they are showing tips for, it's possible to lose the hover state of the thing the tooltip is highlighting.

I think this might be a regression. I don't remember tooltips being so deep into the button in previous versions of Gutenberg.

To Reproduce
Steps to reproduce the behavior:

1. Compose a new post
2. Hover over a toolbar button for a few seconds
3. Hover over the tooltip when it appears
4. Button hover state is lost

Expected behavior
I expect the tooltip to not overlap the thing being hovered over.

(I also expect tooltips to be more timid than Gutenberg's; they feel too persistent, and take too much focus and attention away.)

Screenshots

Desktop (please complete the following information):

• OS: macOS
• Browser: any
• Version: latest

Additional context

• WordPress 5.0 RC 1

[markjaquith]

@JJJ What things have tooltips and trigger menus that require constant hovering? All the ones I tried stay open indefinitely, even if you massively mouseout. They require a click elsewhere to close.

[JJJ]

@markjaquith None of them require constant hovering, which is also unlike most other menus, and probably a separate issue IMO.

The bug here, is that the tooltip covers the thing it’s a tip for, and hovering over the tip doesn’t hide the tip. Instead, it interferes with the rest of the UI state, including the thing being hovered over.

I also think it’s odd having a tip floating on top of, in the way of, anything that drops down like a menu from the button that the tip is for.

[designsimply]

Tested and confirmed that button hover state is lost when hovering over a tooltip. (10s)

^{Tested with WordPress 5.0-RC1-43945 and with WordPress 4.9.8 and Gutenberg 4.5.1 master @ e4fd51cb5 using Firefox 63.0.3 on macOS 10.13.6.}

I expect the tooltip to not overlap the thing being hovered over.

Adding the Needs Accessibility Feedback label to check whether changing how tooltips currently operate would impact accessibility in an unwanted way?

Tooltips […] feel too persistent, and take too much focus and attention away.

Adding the Needs Design Feedback label to ask whether tooltips should be made less persistent.

[afercia]

Discussed during today's accessibility bug-scrub. Seems there are 3 main points here:

• tooltips persist on hover
• tooltips position
• buttons focus style

Re: the first item, the WCAG require tooltips to be:

• hoverable
• persistent
• dismissable

The first part was implemented in #8033. For more details and the rationale, please read the PR and related issue.

References:
Success Criterion 1.4.13 Content on Hover or Focus
https://www.w3.org/TR/WCAG21/#content-on-hover-or-focus
https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html

The last part: dismissable, is still to implement and See #8147 is an attempt in that direction. No great progress there though.

The other items seem separated. Any improvement to the position of the tooltips and to the buttons focus style would be very welcome. Worth noting the buttons don't show their focus style because they're actually not hovered when hovering the tooltip.

[mapk]

Talked about this in today's slack meeting.

Looks like we'll need to investigate common tooltip patterns more in addition to @afercia's comments. A link that might help here was suggested by @paaljoachim : https://www.nngroup.com/articles/tooltip-guidelines/

[mapk]

Okay, for the solution here, let's try just moving the tooltip down so it can't be hovered.

[ItsJonQ]

@afercia Halloo! 👋

---

Update: I just realized the date of the comment 🤦‍♂ . It looks like these interactions have been added, at least from my recent testing.

But! If there still outstanding issues related to Tooltips/Popovers, I'm happy to help with them 💪

---

Those are some great points. Tooltips (and elements similar in nature, e.g. Popovers) are really tricky to get right.

Focusing just on the Tooltip, I took a look at the code, and it looks like there's some JS/React things we'll need to help with:

* hoverable
* persistent
* dismissable

I'm happy to take a look to see what I can do 💪

Do you know of a good examples of this in the wild?
In any particular app or component library/framework?
It would be helpful for me to poke at it :)

For clarification...

For "dismissable", how shall the Tooltip be dismissed?
I've seen this implemented several ways. Just wanted to get your thoughts :).

A couple of common ones are:

• clicking the original trigger
• esc on your keyboard
• tab focusing another element, blurring the original trigger

Thank you! 🙏

[ItsJonQ]

Okay, for the solution here, let's try just moving the tooltip down so it can't be hovered.
@mapk

Update! I think @ellatrix has a solution here:
#17867 (comment)

(@ellatrix , please correct me if I'm wrong :D)

This update adds extra functionality to Popover, which adds the ability to add extra space via anchorVerticalBuffer / anchorHorizontalBuffer.

Once this has been merged, we can make sure it's available for Tooltip. With that, we can add extra spacing in between the Icon ("anchor"), and the rendered Tooltip.

[enriquesanchez]

I'm just seeing your lastest comment @ItsJonQ. Does that make my PR unnecessary then?

[JJJ]

Re: the first item, the WCAG require tooltips to be:
hoverable
persistent
dismissable

These are not correct. See: http://w3c.github.io/aria-practices/#tooltip

Emphasis mine:

Tooltip widgets do not receive focus. A hover that contains focusable elements can be made using a non-modal dialog.

They are not focusable, hence not hoverable, and if there is a need for something inside of a Tooltip to be focusable, a non-modal dialog should be used as an alternative.

Nothing about hoverability. Their persistence and dismissibility is contextual based on how they are displayed/invoked (focus, hover, etc...)

---

Do you know of a good examples of this in the wild?

GitHub. GitLab. macOS. Windows. Ubuntu.

In any particular app or component library/framework?

Framework7. Bootstrap. Semantic UI.

See also: https://github.com/DavideTriso/aria-tooltip
And: https://davidetriso.github.io/aria-tooltip/

---

@enriquesanchez Your PR is definitely an improvement, but the 5px padding doesn't fully prevent the possibility of hovering over a tooltip.

[ItsJonQ]

@enriquesanchez Hai there!

Does that make my PR unnecessary then?
#18144

Just checked out your PR. It's related, but it doesn't make your PR unnecessary.

The awesome addition that in @ellatrix's PR is to provide the ability to add spacing between the anchor and the popover box. But it doesn't look like it adds it by default.

The solution you had in your PR actually adds spacing, but from a CSS perspective, and only for that spot (tab bar)

The anchorBuffers in @ellatrix's enhancement allows for that to be done at the component level.

---

Your PR is still valuable, and will help!

Once the anchorBuffer update gets merged, we can go back to refactor the CSS solution for a React prop-based one :).

Hope this helps!!

[JJJ]

Tooltips (and elements similar in nature, e.g. Popovers) are really tricky to get right.

That's exactly the problem, IMO. WCAG is attempting to redefine what Tooltips are. They are easily lumped them together with Pop-ups and Pop-overs, but that's a mistake.

(Forks and spoons have a lot in common. We use them similarly, wash them at the same time, and they usually live in the same drawer. Their separate existences as utensils are solely based on addressing unique user needs – scoop vs. stab.)

29 years of GUI based operating systems (and their a11y issues) have defined Tooltips as hints-on-hover/focus, starting with Bubble Help in Mac OS 7, and Tooltips in Microsoft Encarta (which eventually became a native Windows API) ultimately leading to the title tag being abused, so much so has been, sadly, basically abolished.

It reads to me like Gutenberg (hence WordPress) jumped the gun to implement Tooltips in a way that aren't part of any finalized spec. Should they even be reinventing Tooltips? How does that help democratize publishing?

More fun reading:

• https://sarahmhigley.com/writing/tooltips-in-wcag-21/
• Clarify the use of role=tooltip w3c/aria#979

This comment is particularly well written:

• Clarify the use of role=tooltip w3c/aria#979 (comment)

Designers and users have made it clear that automatically popping up a tooltip in the editor every time the text caret moves into a class/method/variable or annotated line is terrible UX (very "in your face", obscures code, "too much information I don't need right now", etc).

This is what we have currently.

The tooltips that provide a name are there for sighted users to make sense of an icon. Referencing name tooltips with aria-labelledby ensures that the same name is used for screen reader users.

@scottaohara I've never noticed the problem you mentioned in 987 (comment):

navigating to an element and having its accessible name exposed, and then attempting to navigate away but encountering the accessible name again.

because a screen reader user wouldn't bother opening a button's tooltip when they already know its name.

IMO, the only reason Tooltips are tricky here, is because different (awesome) people are trying to apply their areas of expertise to a single, simple element, resulting in it being a Swiss Army knife and no longer a Spoon.

[afercia]

These are not correct. See: http://w3c.github.io/aria-practices/#tooltip

Randomly quoting specifications that are work in progress doesn't greatly help in understanding the issue. As of October 2019 that specific ARIA Authoring Practices design pattern is marked as "work in progress" and points to the related GitHub issue w3c/aria-practices#128 which shouldn't be considered in any way a recommendation.

At the beginning of this issue I recommended to carefully read #8033 and #7004 for a good understanding of the actual problem. The relevant specification here is WCAG 2.1, as mentioned in #8033 and #7004.

Success Criterion 1.4.13 Content on Hover or Focus
https://www.w3.org/TR/WCAG21/#content-on-hover-or-focus
lists the 3 principles to meet:

• Dismissable
• Hoverable
• Persistent

No one said tooltips need to be focusable. Not I, at least 🙂

For a good understanding of how these principles apply to low vision, screen magnification, motor impairments, etc. see:

Understanding Success Criterion 1.4.13: Content on Hover or Focus
https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html

Has anyone actually read the WCAG understanding? I have the impression most of the feedback on this issue is based on personal opinions while I'd like to remind everyone the WCAG are based on years and years of research, user testing, and data.

let's try just moving the tooltip down so it can't be hovered.

Noting again that tooltips must be hoverable and persist on hover.

They are not focusable, hence not hoverable

Not sure I understand, non-focusable elements can still be hovered, right? @JJJ ?

Do you know of a good examples of this in the wild?

None, unfortunately. The requirements are very clear though, please just read them.

That said, if it was up to me I would never use tooltips to start with 🙂 Tooltips are a perfect way to hide the UI controls names from users who need them the most. Tooltips in Gutenberg are a remediation to the desire from design to implement icon-only controls. A remediation I'm not particularly happy with. A good, universal, user interface shouldn't use icon-only controls. This was debated at length, see some references here: #10524 (comment)

Ideally, icons should always be accompanied by text labels. There are years of discussions around icons and I'm not going to repeat all the argumentations. For accessibility (and I'd say also for usability) they're far from ideal.

Worth reminding there's a pending PR proposing to use text label together with icons, which would reduce the need to use tooltips in the first place. See #10524
I'd greatly appreciate some focus on that PR rather than focusing on tooltips. In the long run, tooltips should be entirely removed together with the only reason why they were introduced: icon-only controls 🙂

[scottaohara]

It's worth remembering that WCAG is a normative specification. ARIA Practices (APG) is a note, and is only informative. APG is also in process of revising their WIP pattern to better adhere to WCAG 2.1.