-
Notifications
You must be signed in to change notification settings - Fork 355
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
tooltips closing with Escape is an irregular UX practice #2538
Comments
If by this you mean that tooltips are just going to disappear on their own, this causes obvious issues for someone who cannot locate/read the tooltip before it disappears.
Note also that the dismiss requirement means moving off of the content is insufficient. You must be able to dismiss without reorienting (unless it obscures nothing, which is impractical to ensure)
I am not familiar with this use of
Yes, that is the origin, and you'll notice how mouse-biased the origin is. A keyboard user couldn't even reach the buttons on those toolbars. that was okay, because the keyboard user could do everything from the menus (including discover shortcuts). We can't rely on the same paradigm on the web since we've totally lost the principle of all functionality being offered via application menus to keyboard users. So users need to be able to navigate to items, discover their names/purpose via tips, and then dismiss the tips. An established mechanism for dismissal is Esc.
I agree that when you have something like the Start menu, which is collapsed with Esc, then it becomes a bit challenging to dismiss tooltips in the menu itself. Almost all menu items have persistent text labels, so tooltips should generally be unnecessary. Those 5 icon-only start button items are definitely a minority. And btw, Ctrl is not an exclusive key; I can dismiss the tooltips with |
No, that's not what I mean. Transient in this case means they only serve a temporary purpose and not meant to be long-lived on the DOM (ie: constantly referred to). The tooltip only has to exist while the element is focused, while the cursor is hovering, or touch is pressed. It is short-lived. It is transient. Users do not consider a tooltip to spawn a new context like a popup or dialog. The tooltip will disappear as easily as it appeared (eg:
You might want to check Wordpad again. If you are focused on the toolbar, and have a tooltip open, wordpad.tooltips.mp4And yes, if you press
Yes you could. You can press alt and tab/arrow keys to reach them. As you can do on Wordpad. I work with keyboard users primarily and again, I have never seen an application outside of jQuery that closes tooltips with
Not on Windows 11 Start Menu, at least. And just because things are a minority, doesn't mean we should ignore the accessibility concerns. Shift doesn't work for me at all on Windows Start Menu, but does for Wordpad (as does any key). With the Windows Start Menu, neither |
Another example with Google Chrome's tooltips: Attempting to close a tooltip with chrome-esc-tooltip.mp4Pressing |
My recollection is Alt got you into the Menu bar and then you arrowed around in the menus and they were circular (press right arrow on the last one and you went to the far left one). You basically just escaped back to the main window. I don't remember a tab ring between the menu and the toolbar . But I don't have a 95 box kicking around to check that :) Both the Windows Start menu and the Chrome site icon in the navigation are not in the actual web page. They're OS and user agent, respectively. And obviously Wordpad is a desktop app. It's important to compare apples to apples. I probably didn't make the desktop vs web division clear enough in my comments. The use of Esc for dismissal on the Web is very common, including dismissing transient content like tooltips when triggered by keyboard focus, etc. ARIA is basically following the AGWG guidance on use of Esc (although I don't think its use is prescriptive). So opening an issue there may make sense. I'm not sure most would think of dismissing web content with Ctrl; surfacing that is going to be a primary challenge. An easier thing may be to just say something like 'where Esc dismisses the parent container, pressing other modifier keys can also dismiss tooltips' |
That's my point. It's only in web. As a PWA developer, this is extremely awkward and causes needless confusion. I can't find any other instance of tooltip closing with Most things are pretty 1:1, or close. Combobox is pretty close (if not exact) to .NET Combobox, with From the ARIA practices information on keyboard, we want to keep it pretty close (emphasis mine):
https://www.w3.org/WAI/ARIA/apg/practices/keyboard-interface/ MacOS is pretty subpar, IMO, with keyboard navigation (off by default) and I don't test much with Linux. So I'm leaning a bit heavily on "What does Microsoft do?". I don't have the best sample size, but most users don't press Escape on tooltips, and everyone I've asked (small sample size) expect I'm not fully advocating for |
One thing you also have to keep in mind is screen reader precedent. JAWS for example has been using the Control key to cancel speech for over 30 years now, and if you assign this keystroke along with Shift to specific actions they will never be discoverable by standard screen reader users. I have been using the Escape model for over 15 years when building components such as these As far as tooltips passing the keystroke up to the window and cancelling load, I'm not sure how this would apply when tooltips on a page need to be interacted with to show a tooltip which can only be done after page load. Even so though, if this is an issue, ensuring that you add stopPropagation() on the tooltip control will prevent this from occurring. |
@accdc In my opinion, this is not a tooltip. That's a popup/info-box. It spans 4 rows and is largely obtrusive. Anything that large will make sense to press Escape. This, on the other hand, is the native tooltip as rendered by Chrome: And that also closes with The custom tooltips on this page don't have parity with native tooltips. So, users have to treat one (custom) tooltip different than another (native). |
But native html tooltips (i.e, user agent behaviour on title) do not get exposed by keyboard, so we are treating them differently. Thanks @accdc for mentioning the 'stop speech' feature of most screenreaders from
The problem with this approach is that it assumes users are going to be aligned on an understanding 'oh this is just simple interaction, so I'll use this key (be it Ctrl or whatever) to dismiss the content, but here I'll use Esc.' I'm skeptical that 2 non-interactive items that share many features (no X to close; no actionable items; appears on focus) will be perceived as fundamentally different interactions by most users. |
The point is that native html tooltip can be dismissed with
I already addressed this, previously.
If Ctrl is a concern with closing tooltips, then Escape is also a concern and has heavier side-effects, so should at least be consistent.
Which I addressed in the first comment:
Something that large are popups. Let's take Microsoft Windows, for example, which is one of the native OS we're supposed to imitate: If you press Windows+T, you will focus on the bottom taskbar. If the application is active, you will get a preview panel that popups. It's rather large and obtrusive. While your focus my be on the application button (shown by outline), a popup will appear. Pressing Now if we move to an application that is not open we get a real, native tooltip. It's short-text and small. So again, we should actually apply what the practices say about staying close to native, and possibly need to split "tooltip" into something else, because I feel developers are just using "tooltip" for something that isn't really a tooltip. It's a pop-up. |
I reiterated the JAWS consideration because it is Ctrl, not Esc that is the advertised key for stopping synthesizer reading. After pursuing your comment, i was surprised to find that yes Esc also seems to pause speech in JAWS --although doing so can obviously also trigger other unintended Esc behaviour (in other words, JAWS isn't trapping Esc). It's an interesting discussion. Philosophically, I'm all for trying to align with OS behaviour for keys. I just see some challenges. I'll step aside and let others participate. Thanks! |
@mbgower Thanks for the discussion! Please, don't take any of my objections, personally. I really appreciate all the points you've shared. I know there's no silver bullet solution to this, but I would like to hash out all the details before I finalize and ship my implementation. |
From Microsoft's usability study (link pulled from the vscode issue that mentioned this): https://www.youtube.com/watch?v=lb0_v7D4kbs&t=1548s
|
The ARIA Authoring Practices (APG) Task Force just discussed The full IRC log of that discussion<jugglinmike> subtopic: tooltips closing with Escape is an irregular UX practice<jugglinmike> github: https://github.com//issues/2538 <jugglinmike> jamesn: WCAG requires this--there's always a risk that the tooltip will obscure content, so you always need a way to dismiss it <jugglinmike> jamesn: If this is irregular behavior that WCAG is requiring, then the issue should be raised with WCAG <jugglinmike> Matt_King: I don't take WCAG's recommendation as unquestionable. I'm willing to push back on WCAG, and we have done that in the past. In this case, though, I agree with WCAG |
Thank you for bringing forward this concern. The discussion in this issue is insightful, and I also deeply appreciate how respectful it has been as well. You are right that the APG tooltip pattern could be improved by emphasizing the importance of positioning to avoid obscuring important content. That creates potential for improving experiences. However, it would not reduce need for keyboard methods of dismissing tooltips. Your observation that there is a potential inconsistency between the principle of modeling native behavior to promote learnability and the guidance to use Escape to dismiss tooltips is an important consideration. When thinking about this, though, it is important to Keep in mind that learnability and discoverability are the goals and modeling native behavior is one approach to achieving them. In some circumstances, there may be other factors that could contribute as much or more to achieving those objectives. I believe the rationale for the WCAG suggestion of Escape is related to learnability and discoverability. With that in mind, some relevant questions related to assumptions about what users know and how they learn might be:
Some solid research to answer questions like these could go a long way. Issues #127 and #128 are nearly 7 years old and have over 100 comments between them! I believe this is evidence that the APG Task Force is struggling to assess what "regular UX practice" is when it comes to tooltips. So. a primary question I have is what are some options for successful resolution of this issue in your mind? Is it possible that this is more of a WCAG issue and not so much an issue for APG? |
It's also worth pointing out that the 'Russian doll' problem mentioned here (dismissible info in something that is itself dismissible) is not necessarily only 2 layers deep. In other words, having a second dismiss key doesn't solve everything. At some point, the author (or user agent) is going to have to isolate the dismissal to only the 'top' layer of dismissible content with some kind of key listener. @smhigley I had a look at your video that @clshortfuse posted above. Can you give us some more details on the number of folks in your study and some more particulars: number of users, keyboard preferences, etc? As per Matt's comments above, we need data, so it would be useful to understand what is gathered to date. |
I believe an emphasis on user expectation is probably warranted in the guidelines. Long story short, tooltips can be confused with non-modal dialogs and authors should tap into user expectations, and be careful not to work against them. That may include simplifying visual aspect of tooltips. The discussion of
I see I took a second look at different UIs and see there's also a level of expectation of "overlayed" content. For example, Another aspect is that the popups have the ability to take focus. They all show some sort of focusable element, even if they don't immediately take focus. For example, some comboboxes pop up a list, but don't always immediately show focus in the list (manual selection). Because the list is focusable, the popup can be closed with Escape. Even the example of the Windows taskbar navigation with images that closes with I did notice the guidelines state:
I think to myself, "What is the tool for which a tip is needed?", and it doesn't have one. It's not a tooltip. It's not a hint for an action (tool) the user will take. It's more likely a non-modal dialog. It should be similar to (TL;DR): Tooltips should be non-interactive and not "rich" in anyway. They should be small, unobtrusive, suggestive (unimportant) and dismissable with More complex or important popups would be non-modal dialog which are closed by Authors should apply sufficient differing visually styling to differentiate between Side note: @smhigley has a write-up here about tooltips here which seems mostly inline with my findings. It predates the YouTube about a year and there's no mention of the |
@clshortfuse, Carbon has come up with a similar model for an interactive overlay, also called a toggle tip. The key distinguishers from a tooltip being:
Note that a toggletip's disclosed child, while the trigger still has focus, can be closed by toggling the trigger again. Such a division has worked fairly well between 'true' tooltips and an interactive form of temporary disclosure, but I'll add a caution that the other side of this continuum is probably even more tricky to try to delineate (i.e., when does a toggle tip become so interactive that it is no longer a toggletip but something else?)
I would call that inaccurate. Why can't a disclosure cover other material? It occurs all the time; maybe you are meaning something else when you say 'disclosure' (which describes a vast set of interactions, depending on who you talk to). In short, a menu that is disclosed and overlays other content is a much different 'disclosure' than an accordion, which shifts all content so that no information is obscured by its expansion.
A caution about non-modal dialogs. That can also mean VERY different things to different people, and the specifics of the term, as hinted at by Aria documentation, speaks to a prescribed interaction which I don't think aligns with what you envision. |
It seems the aria practices seem to suggest closing tooltips with
Escape
, but I can not find any example of a system UI that implements this behavior. I was only able to find this with jQuery but nowhere else.For example, Windows will close the Start Menu is you press Escape while a tooltip is shown:
I can understand an interactive popup element closing, but users generally do not perceive a tooltip to be interactive and see them as transient, leaving by blurring focus or moving away (or releasing hold if on touch).
At the same time, it important that tooltips do not obscure content:
https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html
The WCAG guidelines do state there are two method, which I feel the ARIA practice minimizes and only focuses on one:
We should strive for method 1 and option 2 should, in my opinion, be a last resort. It would be best practice to not introduce irregular UX practice (press Escape) which would be web unique and users may already resist using said interaction. For example, a tooltip in a dialog or popup (like Windows Start Menu), triggers a close, escaping the context they are in. If
tooltips
are transient, then they shouldn't really be "escaping" said context.Authors should be encouraged to apply method 1, and if their tooltips are "rich" enough to allow be obtrusive, consider not styling it as a tooltip, and instead as a popup. For example, Google's Material Design guidelines suggest:
https://m2.material.io/components/tooltips#placement
If we look into the history of what a "tooltip" is, it was originally meant as a tip for toolbar items. It dates back to Word 95. There were icon buttons that didn't have any text associated with them, so it made sense to have a short tip which rarely more than one or two words. If authors are creating complex, obtrusive popups, I'd argue those are not tooltips. Those are pop-ups.
It may be from the lack of an alternative that ARIA practices are written like this. If I wanted an information popup, nothing exists. It must be either a menu, listbox, tree, grid, or dialog. Something like this on Google Maps could, maybe, be considered a dialog?
And in this case it's so large and obstrusive, that I would think Escape will close it (and it does on Google Maps).
Edit: It seems Windows will close a tooltip on
Ctrl
keypress, which is a much better implementation, in my opinion.Alt
andShift
do not close a tooltip, so it seems it's not just any keypress. ChangingEscape
forCtrl
will satisfy the WCAG criterion without confusing UX patterns.The text was updated successfully, but these errors were encountered: