How to make popover open on hover in desktop (not a tooltip), and keep its original behavior on mobile devices

[felquis]

Hello, recently I'm using Popover

People asked if it is possible to make it show up when the user hover the cursor over the trigger on desktop
keeping its original behavior on mobile devices.

I couldn't find anything about it in the docs, so I switched to the tooltip. BUT afterwards I figured there's no tooltips on mobile - also learned a few things about it on previous issues #955 and discussions https://github.com/radix-ui/primitives/discussions?discussions_q=tooltip+popover+

Suggestions:

• State at the Tooltip doc that it won't showup on mobile devices, touch only in general https://www.radix-ui.com/docs/primitives/components/tooltip - there's some relatable previous comment [Tooltip] Tooltip component doesn't work on iOS Safari (14.4)  #955 (comment)

PS: Stripe has an interesting implementation of this behavior as a tooltip, cause it is a link https://stripe.com/docs/api/file_links/object#file_link_object-file in the "expandable" line:

The first click, opens the "tooltip" or popover I guess, and the second click navigates to the link. At desktop, the hover opens the "tooltip" or popover, and the click navigates to the link content.

The same behavior can be seen on internal dashboard pages, on action links and on extra info popovers. This behavior on stripe was the main reason why I was after this behavior. Tested on iOS simulator.

---

Since this question has been raised a few times, doesn't it look like an expected behavior from popover or even tooltips in general?

---

My current potentially dangerous workaround:

import * as Tooltip from "@radix-ui/react-tooltip";
import { RiInformationFill } from "@react-icons/all-files/ri/RiInformationFill";
import { useState } from "react";

export default function InfoTooltip({ text }: { text: string }) {
  const [open, setOpen] = useState<boolean>(false);

  return (
    <Tooltip.Provider delayDuration={100}>
      <Tooltip.Root
        onOpenChange={(e) => {
          setOpen(e);
        }}
        open={open}
      >
        <Tooltip.Trigger onClick={() => setOpen(true)}>
          <RiInformationFill />
        </Tooltip.Trigger>

        <Tooltip.Portal>
          <Tooltip.Content>
            <Tooltip.Arrow />
            <p>{text}</p>
          </Tooltip.Content>
        </Tooltip.Portal>
      </Tooltip.Root>
    </Tooltip.Provider>
  );
}

PS: already negotiated with the team, and we'll be using Popover in its current radix behavior implementation. BUT I wanted to create this discussion to hopefully bring awareness about the subject.

Thank you for your time and have a good day.

[benoitgrelard]

Hey @felquis, thanks for taking the time to write this up.

The issue is that there are distinct accessibility patterns/issues with different behaviours.

For example, the Stripe examples you post are inaccessible via keyboard. Furthermore tooltips shouldn't contain interactive content (for the same reason, because you can't reach it).

You could try to hack Popover so it opens on hover only on desktop, but then what happens for keyboard?
As you can see there are a lot of considerations to all these interactions, hence why we suggest to stick to the established patterns as much as possible.

[felquis]

Hey @benoitgrelard sorry if what I'm saying have already been told before.

What if, we write down what are the acceptance criteria for the popover and tooltip functionality. (maybe its already written somewhere you can link us to) and then let the community figure what could be a good overlap of functionality.

In practical terms, as in, using keyboard, voiceover and/or other accessibility tools - what are the expected behaviors.

1 - What are the accessibility steps and assertions that makes tooltips acceptable.
2 - What are the accessibility steps and assertions that makes popover acceptable.

And based on this practical information, the community can reproduce and try both understand better how popover and tooltips accessibility requirements works.

And then use it to propose what could possibly work for this.

The final results could end up as modifier property in the popover component.

---

In this discussion, it is clear what is the visual effect people would like. But, it's not clear what is the accessibility issues that blocks us going to that direction.

---

I'm sorry I'm not too literate on the accessibility matter.
But I hope this comment can help rather than disturb the discussion.