-
Notifications
You must be signed in to change notification settings - Fork 48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Tooltip doesn't work on iOS #682
Comments
Ah yep, I see what you're saying. Question for you: what is the behavior you would expect from tooltips on mobile devices? A) Not show at all (because there's no hover on touch devices) Here are two examples of different behaviors I found around the web:
Just want to see what people expect before we explore this more. |
I would go with option B: show on tap and allow the thumb press to trigger click listeners as well. I wouldn't ever use a tooltip for buttons to be honest, but that may just be personal preference. I think the expectation for buttons is to perform the action the button suggests and nothing else. If you want to show a tooltip, sure, but do the expected button action too. I was thinking more in terms of things like these, where the information is most commonly found on tooltips than an expandable text area or similar: In the above case, it's information that you need only the first time that you use the form, so it would clutter the UI if we had it always be present. As far as the other options, here are my opinions:
This is the one I like the least as it requires two different designs, for mobile and bigger screens.
This messes with the normal expectation of a control. If it's a button we should be able to tap/click it and have it do what it's expected to do.
This one is tricky because it depends on how mobile implements selections. In iOS if you hold, you get the text selection options, dictionary, translation, etc., so it looks messy. I like this in terms of usability but in the real world I'd avoid it. |
Just as another data point - HelpScout on mobile has all clickable elemetns (buttons, table rows, etc) using option C (show tooltip on first tap and actually click on second), and I really dislike it. I just want to be able to click on the thing I'm trying to click on. Having to click everything twice is a pain. |
Yeah I agree that a double click is annoying for users. Josh, can you verify that people can make like an "i" (info) icon with a hoverable (press/hold) action to display it on mobile, and report back your findings? |
@calebporzio I've investigated this and there isn't currently a way to press and hold with how tooltips and buttons are currently structure. So I've submitted a PR to Flux Pro that adds long press support to tooltips, see livewire/flux-pro#113 How it works in that PR is the same as option D, where touching the button triggers the button action, but long touching the button shows the tooltip and does not trigger the button action. An alternative to this would be to add a flag to the tooltip component that allows it to listen to clicks and be toggled directly, that way an "i" info button could trigger the tooltip. Edit: I just read back through @poisa's comment about option D regarding the text selection issues on iOS, so I have updated the PR to include disabling text selection during a long touch on the tooltip button. |
I've done a deeper investigation at @calebporzio's request into how other libraries handle tooltips on mobile and what the accessibility guidelines say. Before we can discuss whether a Tooltip should be available on mobile or not, it's best to define exactly what a tooltip is first. What is a tooltip?According to ARIA Authoring Practices Guide:
This definition would suggest that tooltips are only for desktops as mobile devices typically don't use a mouse or have keyboard focus for things like buttons. But there is no definition of what to do on mobile devices and the ARIA guide has a note that it is a work in progress. Tooltips can be used on buttons and links, but they can also be used on input elements as an additional description for how to interact with the input. Reading through some of the discussions, listed below under References > Tooltip definitions, it would seem that authors of other libraries also have troubles deciding exactly what a tooltip should and shouldn't be. Some of the clearer definitions I found though was in Radix, ShadCN, and Melt UI, and that was:
Their reasoning for this is that any form of "touch" interaction to display the tooltip:
The word tooltip has become conflated to mean multiple things:
One complaint of Radix, etc. is that it's unclear in their documentation when their tooltip component should be used vs their popover component. What should Flux do?Below I've compiled two lists of libraries that have tooltips that work on mobile (and what they do) and libraries that don't. An interesting solution that Chakra UI has, is that they have a two "tooltip" components, a traditional "tooltip" and a "toggle tip" - which has the description "Looks like a tooltip, but works like a popover." Their "tooltip" on desktop works with hover and keyboard focus and does not work on mobile. Their "toggle tip" has a dedicated trigger button, such as an "i" information button, and displays a popover that is styled exactly the same as their "tooltip" component. I think we should implement something similar to this, but I believe it could all be documented on the "tooltip" page, by adding a dedicated We would then have a warning that tooltips (on hover) don't work on mobile devices and that it would be better to implement a tooltip trigger if they want it accessible on mobile. This hopefully stops users being confused as to how to implement what they're after. If we do actually want to make a traditional tooltip work on mobile, then I think showing the tooltip when the button is clicked, and firing the button action at the same time, would be the best option. It's not particularly accessible as far as the tooltip is concerned, as the action might fire before the user can see the tooltip, but it might be better than nothing. The advantage for implementing this is if the tooltip component is used on an input element, then the tooltip can add descriptive text for the input and function correctly on mobile. ReferencesLibraries that tooltip does work on mobile
Libraries that tooltip doesn't work on mobile
Tooltip definitions
Other libraries tooltip components
|
I've nothing useful to add to this other than to thank you all for the amount of work, detail, and love you put into everything! Looking forward to seeing Flux evolve! |
What we have settled on for now is to add a <flux:tooltip content="Information" toggleable>
<flux:button icon="information-circle" icon-variant="outline" />
</flux:tooltip> This allows a tooltip to be shown/hidden by a button click/press, instead of on hover/focus as they don't work on mobile. It's good for creating information "i" buttons next to elements, to add some helpful information. |
You can test this in the official documentation https://fluxui.dev/components/tooltip
The first time you try a tooltip there is a chance that it shows properly but often it does not. All subsequent times it fails.
I can reproduce this every single time in both Safari and Chrome for iOS 18.1 on an iPhone 16 Pro Max.
The text was updated successfully, but these errors were encountered: