🐛Bug: For tooltip, ignore delays when on a mobile device

[jasongitmail]

Describe the bug
When on a mobile device, tapping the tooltip waits the specified delay, but should show it immediately.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://www.melt-ui.com/docs/builders/tooltip
2. Tap on the example
3. Tooltip is shown after the delay.

Expected behavior
Tooltip should be visible immediately when tapped by a user on a mobile device.

Smartphone (please complete the following information):

• OS: iOS16
• Browser: safari
• Version unknown

[TGlide]

Actually, tooltips should not work on mobile devices. For those, Popover should be used.

[jasongitmail]

@TGlide

I would encourage you think on this more though, and not follow Radix here.

1.) Responsive websites are the de facto standard, 2.) it's not particularly useful as an element with that intentional limitation, 3.) it's current behavior is almost perfect for desktop and mobile already--just needs the delay tweaked on mobile, and 4.) having gotchas in Melt elements that make them inconsistent from other elements will hinder the DX--at the very least, it needs a warning "Use only on non-touch devices", otherwise devs aren't going to anticipate this intentional limitation unless it's noted.

[TGlide]

@TGlide

I would encourage you think on this more though, and not follow Radix here.

1.) Responsive websites are the de facto standard, 2.) it's not particularly useful as an element with that intentional limitation, 3.) it's current behavior is almost perfect for desktop and mobile already--just needs the delay tweaked on mobile, and 4.) having gotchas in Melt elements that make them inconsistent from other elements will hinder the DX--at the very least, it needs a warning "Use only on non-touch devices", otherwise devs aren't going to anticipate this intentional limitation unless it's noted.

It's an accessibility concern, rather than just following Radix and other libraries.

From MDN:

The use of the ARIA tooltip role is a supplement to the normal browser tooltip behavior. An example of a native browser tooltip is the way some browsers display an element's title attribute on long mouse hover. One cannot activate this feature through either keyboard focus or through touch interaction, making this feature inaccessible. If the information is important enough to include as a tooltip or title, consider including it in visible text.

I agree though that the docs should clearly specifiy this limitation!

[jasongitmail]

An example of a native browser tooltip is the way some browsers display an element's title attribute on long mouse hover. One cannot activate this feature through either keyboard focus or through touch interaction, making this feature inaccessible

Your quote refers to the HTML title="foo" attribute behavior, which yes, is inaccessible on mobile.

But Melt's tooltip is not implemented as merely a title="foo" attribute, and consequently it does not have this limitation, and doesn't need to be artificially limited to the limited behavior of a native title="foo" attribute. In fact, it is accessible to mobile users already, which is great; we can just refine the behavior for them by eliminating the delay on tap.

[TGlide]

An example of a native browser tooltip is the way some browsers display an element's title attribute on long mouse hover. One cannot activate this feature through either keyboard focus or through touch interaction, making this feature inaccessible

Your quote refers to the HTML title="foo" attribute behavior, which yes, is inaccessible on mobile.

But Melt's tooltip is not implemented as merely a title="foo" attribute, and consequently it does not have this limitation, and doesn't need to be artificially limited to the limited behavior of a native title="foo" attribute. In fact, it is accessible to mobile users already, which is great; we can just refine the behavior for them by eliminating the delay on tap.

By reading more into what I quoted, it even goes against me. It says the title attribute is inaccessible, not that the tooltip being activated by touch is.

The WAI-ARIA guidelines do not say anything about touch, but do say about receiving focus... I think you've convinced me. Will think a bit on this.

[TGlide]

@jasongitmail one question, why did you prefer to use a tooltip rather than a popover?

Reason I'm asking is, me and @huntabyte have been debating over this recently. I'm also wondering due to this issue: #276

In this issue, the button is both a tooltip trigger and a menu trigger. Which means, you'll never be able to see the tooltip in mobile, due to it correpsonding to an action that moves focus outside of the tooltip trigger.

Also, this behaviour is inconsistent with the desktop behaviour. In desktop, if you already clicked the action, you hide the tooltip (in case it had been triggerred), and prevent it from showing further, unless the mouse moves out and back again from the trigger. Meanwhile, in touch devices, this proposed and implemented behaviour means that even after the action is executed, the tooltip persists there in case focus isn't changed afterwards, which is not something you'd expect after seeing the desktop behaviour.

Continuing my research. looking over to the tooltip section in MDN, it is meant to provide additional information, and not be directly requested. Meaning, something like a ⓘ shouldn't be called with a tooltip (which is what I assume you were using, or something similar):

We also debated over this article: https://sarahmhigley.com/writing/tooltips-in-wcag-21/

All this information is making me rethink this re-implemented behaviour, and I'm thinking of reverting it. I'd like your thoughts though!

[TGlide]

Linking the #279 PR as a resolution.

[jasongitmail]

@TGlide No preference for tooltip vs popover. My goal was to help test MeltUI for DX/UX and avoid unexpected behaviors.

In this issue, the button is both a tooltip trigger and a menu trigger. Which means, you'll never be able to see the tooltip in mobile, due to it corresponding to an action that moves focus outside of the tooltip trigger.

I researched this more and it seems super unclear.

• I can see how you'd read MDN to say tooltip should use hover and popover should require intentional interaction.
• W3C Aria's tooltip pattern "is work in progress; it does not yet have task force consensus". But discussions are captured here, which includes a link to 3 janky examples including one that is a button and tooltip--theirs triggers the button and then the tooltip occurs after it's dismissed haha. Their basic example is touch accessible on mobile.

For practical purposes:

• Bootstrap's tooltip is accessible on desktop via hover and mobile via tap. To me, that seems intuitive.
• Imo, the dev's approach in issue 276 of a button with a tooltip is problematic and not best practice for responsive web design--b/c it overlays an element with a hover event (tap on mobile) on top of an element with click (tap on mobile) event, this will inherently cause issues for mobile users.

TDLR No clear answer. I lean toward the practical approach primarily b/c seems more intuitive DX/UX, and secondarily b/c W3C's example is touch accessible, but maybe go with whichever you feel is best since it's unclear, and just document the foot guns on the tooltip docs.

[TGlide]

Hey @jasongitmail, thanks for your feedback!

I agree that it can be a bit confusing! It did take a lot of research for sure.

Please note we still have an option to have the tooltip work on mobile. By setting closeOnPointerDown to false, if the trigger is focusable, the tooltip will appear, similar to Bootstrap. If you set openDelay to 0, it will work exactly the same as Bootstrap's example.

We'll be also dispatching custom event listeners for every listener we currently have, as well as controlled usage, so the ignorable delays should be achievable. It's just not something I think should be on by default. I thought of having it configurable, but I think the event listeners I mentioned should be more than enough.