Update tooltip appearance

[jameskoster]

Tooltip background color is the same as the background in the site editor. It would be good to update the appearance so that they can be interpreted as discrete elements. Changing the background color, or adding a drop shadow are two options to explore.

[jasmussen]

I think we can go all black on the tooltip, potentially, but I wouldn't add a shadow. The text is legible, after all.

A more urgent thing we need to fix, though, is that the tooltip appears to invoke simply on focus, making it linger when you just click the item:

It should only ever appear if you hover and pause. @ciampo do you know if this is a regression? I believe it used to work.

[jameskoster]

I think that one is worthy of a separate issue. I wonder if showing the tooltip on focus is an a11y requirement?

Agree a black background would be a quick and easy fix.

[jasmussen]

I think that one is worthy of a separate issue. I wonder if showing the tooltip on focus is an a11y requirement?

This is not the case anywhere else, and I don't see how it would be that useful:

It seems like a bug.

[ciampo]

the tooltip appears to invoke simply on focus, making it linger when you just click the item:

It looks like the tooltip is showing on the back button as a consequence of wrapping each sidebar "view" in the NavigatorScreen. As an accessibility feature, in fact, NavigatorScreen moves focus on the first accessible element of each screen — and the back button is the first focusable element in the DOM order.

Re. the "tooltip lingering when clicking", that is a consequence of the behavior just described. Each sidebar "screen", in fact, has its own "back" button. When we click on such "Back" button, we trigger an animation, and a new screen is shown. Because of the behavior described above, the back button in the new screen receives focus and shows its tooltip.

I can think of a few ways to improve the situation:

• We could change the DOM order of each screen so that the element that will be automatically focused will not be the "back" button (for example, it could be the first menu item?)
• We could rewrite the code to use the skipFocus flag, which would prevent NavigatorScreen from focusing the first interactive element (although that may be an accessibility regression)
• We could also spend some time and reconsider if the current behaviour of NavigatorScreen is appropriate, or if we could change it to something more subtle (ie. focusing the screen wrapper instead of the first focusable element)

@andrewhayward, do you have any insights?

[jasmussen]

Re. the "tooltip lingering when clicking", that is a consequence of the behavior just described. Each sidebar "screen", in fact, has its own "back" button. When we click on such "Back" button, we trigger an animation, and a new screen is shown. Because of the behavior described above, the back button in the new screen receives focus and shows its tooltip.

The button receiving focus sounds perfectly fine to me, it needs to be transferred to a logical place so you can continue navigating. So to be absolutely clear, the focus behavior is not what I'm suggesting any changes to here.

What I'm noting is that it feels unexpected to me that focus triggers the tooltip on the back button, when my mouse cursor is no-where near it. Showing tooltips on focus is also not something we consistently do across the UI, note the "Document Overview" example above, which does not show a tooltip on focus, only on hover. What makes the Back button unique in this sense?

[ciampo]

As far as I know, tooltips are always expected to show on both hover and focus events.

With regards to the "Document Overview" button, I tested it on my local machine on the latest version of Gutenberg, and for me, the tooltip shows as expected both when focusing and hovering:

tooltip-focus-document-outline.mp4

[andrewhayward]

Just to confirm, at a general level, tooltips should definitely become visible on focus as well as hover, to ensure non-mouse users have access to the same information. And equally, focusing on the back button here is also to be expected.

I think the confusing thing here is the combination of the two, because the user did not intend or expect to trigger the tooltip interaction. Moving focus to the button makes sense, showing a visible focus ring is questionable if the user didn't use a keyboard to get there, but enabling the tooltip is probably not the right action in this scenario.

[jasmussen]

Thanks for all the feedback! So it sounds like hover and focus should both trigger the tooltip. The gotcha, and probably the solution here, is that the back button currently uses focus-visible to show the focus rectangle when keyboard navigating but not when clicking, which works rather well for handling the disorientation of the drilldown. But it seems like if focus and the tooltip are connected in that way, shouldn't the tooltip also be aware of the focus-visible behavior? That would give us the following:

• Navigating with keyboard, focusring and tooltip are visible on the back button.
• Clicking, shows neither.

[ciampo]

But it seems like if focus and the tooltip are connected in that way, shouldn't the tooltip also be aware of the focus-visible behavior?

The current Tooltip component shows/hides based on the focus javascript event. I'm not sure if it's possible (or even recommended) to tweak that behavior to only show the tooltip when the anchor is :focus-visible. We should also keep in mind that we've been working on a new version of Tooltip (put on hold as we shifted our focus on more urgent tasks), and so any changes to the current version may get lost anyway once we migrate to the new component.

I have the feeling that the best solution here could be to

spend some time and reconsider if the current behaviour of NavigatorScreen is appropriate, or if we could change it to something more subtle (ie. focusing the screen wrapper instead of the first focusable element)

I will have to chat to @andrewhayward to see if this is an option, or to see if we could make tweaks to Tooltips at all

[andrewhayward]

Having thought about this quite a bit, the current situation is in a weird area between pure accessibility and UX. The behaviour as it is would ultimately be correct from an accessibility perspective, but I wouldn't want to say without research what sort of impact it has on UX. Given further work is ongoing, I wouldn't want to suggest changing the current experience, but investigation would certainly be useful to determine what's best for users. It may well be one of those things that isn't a problem at all, and we're only seeing because we're hyper-sensitive to the UI.

[jameskoster]

I'm going to open a PR to address the issue described in the ticket. Since the conversation has diverged entirely from that issue, please feel free to edit the OP.

[jameskoster]

Closing this as the original issue was resolved. Please feel free to open a new one to tackle the pesky "Back" tooltip.