Hover Popover / more robust Tooltip

[selrond]

Provide your feedback here.

There are a couple of issues where people (myself included) were confused to find that tooltip position is off when focusable content is used inside of it:

• Tooltip with Link breaks placement · Issue #7707 · adobe/react-spectrum
• Incorrect positioning of the tooltip when rendering a button inside it · Issue #8547 · adobe/react-spectrum
• Tooltip positioning incorrect when containing a focusable element · Issue #5665 · adobe/react-spectrum

The reason I was doing it was that I needed to display some content on hover, and Tooltip seemed like the most straightforward option.
There was some discussion about wiring up a controlled popover with hover detection, but it’s not trivial to set up.

In my understanding, the reason why the tooltip appears incorrectly positioned is roughly as follows:

1. TooltipTrigger provides ref to the FocusableProvider, which is consumed by all elements that use the useFocusable hook here.
2. That ref is then used in useOverlayPosition for calculating the tooltip position
3. After the tooltip opens, given there’s some focusable content within it, that content replaces the correct ref of the trigger, and eventually the tooltip tries to reposition based on the newfound ref. It happens fast, so most of the time one sees only the end result, even though it can go through multiple repositionings based on how many interactive elements are within it & how they render.

What I had to do to "fix" it, is implement a context barrier, to prevent nested focusable elements from replacing the tooltip trigger ref. It works by setting the ref to null for all its children, effectively making the original trigger ref inaccessible down the tree.

import { FocusableProvider } from '@react-aria/interactions';

<TooltipTrigger>
  <Button>
    Hover me
  </Button>
  <Tooltip>
    // The context barrier
    <FocusableProvider ref={null}>
      <Button>Click me</Button>
    </FocusableProvider>
  </Tooltip>
</TooltipTrigger>

Now I get that it’s inaccessible, but the tooltip is already inaccessible for touch devices, so it serves just as a UX improvement for mouse users anyway.

In any way, I think it could be made more robust (prevent ref leaking to its content for instance), or — better yet — there could be a new component for such behavior (hover popover — an overlay element positioned relative to a trigger triggered by hover). Aria APG recommends using non-modal dialogs for that, so I guess it can be made accessible.

Based on previous discussions, there seems to be a real demand for it:

• How to control the Popover component by hovering? · adobe/react-spectrum · Discussion #4705
• Control popover by hovering and outside interactions · adobe/react-spectrum · Discussion #6563
• Creating a hover activated navigation menu with the Popover component · adobe/react-spectrum · Discussion #7192

🔦 Context

No response

💻 Code Sample

No response

Version

No response

What browsers are you seeing the problem on?

No response

If other, please specify

No response

What operating system are you using?

No response

[devongovett]

Now I get that it’s inaccessible, but the tooltip is already inaccessible for touch devices, so it serves just as a UX improvement for mouse users anyway.

Also keyboard and screen reader users won't be able to access it. With that many users excluded, it seems better to explore a different UI pattern that is more accessible. You will have to find an alternative for those users anyway, so why not make it the same for mouse users too?

Do you have an example of the kind of UI you're trying to build? How would keyboard, touch, and screen reader users accomplish the functionality available in this hover tooltip?

[selrond]

Good point.

One example of a content of such component would be showcasing additional info about an entity in a form of key-value pairs, each with a button for copying the value to clipboard. Pure convenience, all the info is accessible when users navigate to the entity.

I can’t use popover, since the trigger itself should navigate users to that entity, nor the tooltip, since (without special treatment) it suffers from the ref leaking into tooltip content.

[selrond]

What I described above is observable in Linear for instance — hovering over profile shows a tooltip with interactive elements inside (links to workspace, projects etc). Again — all the info is there when a user opens a profile, this is just for convenience. And that’s not the only place they do this at.

[devongovett]

Just because it's a common component doesn't mean it's accessible. See this thread for a discussion about it: https://www.reddit.com/r/accessibility/comments/1kwlwvr/hover_card/

Again — all the info is there when a user opens a profile, this is just for convenience. And that’s not the only place they do this at.

Navigating to a whole new page and potentially losing the state (scroll position, user input, etc.) on the current page is not equivalent to displaying a preview. A preview helps users decide whether to navigate in the first place, so that's the functionality that is not accessible, not the information itself which may be available elsewhere.

An alternative could be to make the navigation on click a two step process. First display the preview, and then within the preview have a "View Details" button to navigate to the new page.

[selrond]

make the navigation on click a two step process

That would be annoying to use.

I get that react-aria is laser-focused on accessibility, so things like these might not fly here, but in reality there are many cases where we devs have to hack stuff together, especially while working on apps that are still shaping up, and perfect accessibility is sacrificed for iteration velocity.

So if (understandably) we’re not going to see anything like the hover card / hover popover as a first class citizen of RACs, could the existing components be a bit more robust (not leak ref etc.) & explicit?

[devongovett]

Possibly. Disregarding the other accessibility issues, I think Tooltip would not be the correct component for this in any case. The tooltip role cannot contain focusable elements. Instead, this would likely be implemented as a non-modal popover. Therefore "fixing" tooltip to work better with focusable elements would probably be the wrong approach. We'd instead consider better supporting displaying popovers on hover.

Some other possible patterns:

• Mouse – display on hover
• Keyboard – display on focus, but don't immediately move focus into the popover like normal. Instead make the next item in the tab sequence move into the popover.
• Touch – maybe long press? Not the most discoverable but long press for link previews is a pretty common behavior on iOS at least. But it can conflict with other gestures like drag and drop or text selection so not always workable.

There's not really a standard pattern for this so it would require a bit more research to support properly.