tooltips closing with Escape is an irregular UX practice

[clshortfuse]

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:

The intent of this condition is to ensure that the additional content does not interfere with viewing or operating the page's original content. When magnified, the portion of the page visible in the viewport can be significantly reduced. Mouse users frequently move the pointer to pan the magnified viewport and display another portion of the screen. However, almost the entire portion of the page visible in this restricted viewport may trigger the additional content, making it difficult for a user to pan without re-triggering the content. A keyboard means of dismissing the additional content provides a workaround.

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:

Two methods may be used to satisfy this condition and prevent such interference:

1. Position the additional content so that it does not obscure any other content including the trigger, with the exception of white space and purely decorative content, such as a background graphic which provides no information.
2. Provide a mechanism to easily dismiss the additional content, such as by pressing Escape.

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:

Don’t display rich information and imagery on tooltips

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 and Shift do not close a tooltip, so it seems it's not just any keypress. Changing Escape for Ctrl will satisfy the WCAG criterion without confusing UX patterns.

[mbgower]

If tooltips are transient

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. Hence the WCAG requirement with Content on Hover or Focus that information persist until dismissed by the user. And btw, the tooltips for Wordpad (just checking a built-in Windows app) meet this behaviour.

Persistent The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

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)

Dismissible A mechanism is available to dismiss the additional content without moving pointer hover or keyboard focus, unless the additional content communicates an input error or does not obscure or replace other content;

---

Changing Escape for Ctrl will satisfy the WCAG criterion without confusing UX patterns.

I am not familiar with this use of Ctrl, and I wouldn't call it an established convention. Esc as a means of dismissing content is quite established. Note that Esc does dismiss the tooltips triggered by hover in Wordpad. In fact shift did as well. In fact any key press seemed to close it (although some also triggered other behaviours).

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.

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.

For example, a tooltip in a dialog or popup (like Windows Start Menu), triggers a close, escaping the context they are in.

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 Shift too.

[clshortfuse]

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.

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: focus => blur, touchstart => touchend, mouseover => mouseout)

I am not familiar with this use of Ctrl, and I wouldn't call it an established convention. Esc as a means of dismissing content is quite established. Note that Esc does dismiss the tooltips triggered by hover in Wordpad. In fact shift did as well. In fact any key press seemed to close it (although some also triggered other behaviours).

You might want to check Wordpad again. If you are focused on the toolbar, and have a tooltip open, Esc will escape your context. Yes it is "closing the tooltip" but it's also ejecting you out of the toolbar navigation and onto the editable content area. It's not really closing the tooltip, it's aborting your context, which was focused on the toolbar. Esc is akin to clicking on the content box. I recorded it to show this:

https://user-images.githubusercontent.com/9271155/201798675-e1d63236-385b-4cda-b114-ce8512c1904c.mp4

And yes, if you press Ctrl in Wordpad, it will close the tooltip without closing any menus or escaping your context.

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.

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 Esc without aborting your current context. And now with Wordpad, that's just another example of how Esc is an irregular practice.

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 Shift too.

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 Shift, nor Alt work. Only Ctrl does.

[clshortfuse]

Another example with Google Chrome's tooltips:

Attempting to close a tooltip with Esc will abort a page load:

https://user-images.githubusercontent.com/9271155/201801015-d17d5b94-dfe8-424a-ba5a-cf4c0098b1dc.mp4

Pressing Ctrl or Shift will close without any unintended consequence. Tab or Alt will close, but will shift currently focused control.

[mbgower]

Yes you could. You can press alt and tab/arrow keys to reach them.

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'

[clshortfuse]

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.

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 ESC. I care about how the users are used to interacting with applications. They shouldn't have to think "Oh, this is a website, so it works different than every other convention." And it makes it even worse when PWAs are styled to look native, which IMO is the objective of PWAs. (I used to write C#, Android, and iOS and now just write for Web.) Most users don't know they're "in a web page" other than the fact they hit Install PWA months ago (or had it preinstalled by the IT).

Most things are pretty 1:1, or close. Combobox is pretty close (if not exact) to .NET Combobox, with Ctrl/Shift,Esc conventions. Same applies to tabbing and ListBox. So when moving from WinForms C# to Web, my users didn't really have much issue. Everything functioned exactly as it used to. (And before that my users were used to DOS-based applications with no cursors at all.)

From the ARIA practices information on keyboard, we want to keep it pretty close (emphasis mine):

ARIA roles, states, and properties model accessibility behaviors and features shared among GUI components of popular desktop GUIs, including Microsoft Windows, macOS, and GNOME. Similarly, ARIA design patterns borrow user expectations and keyboard conventions from those platforms, consistently incorporating common conventions with the aim of facilitating easy learning and efficient operation of keyboard interfaces across the web.

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 Esc to close what they're working on.

---

I'm not fully advocating for Ctrl. It's not a perfect solution. Ctrl will stop reading on NVDA. (Though to be fair, so will Esc) But as I'm rewriting this generation of Web Components, Esc for tooltips is just opposed to what users are used to. An interactive/rich popup, makes sense, but not short tooltips. So this would be the first component I write that goes against ARIA Practices guidelines.

[accdc]

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 https://whatsock.com/Templates/Tooltips/Internal/index.htm and I have never had a complaint that this keystroke was too obscure to be understood.

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.

[clshortfuse]

@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 Ctrl. Pressing Escape will close it as well, but will also perform a default interaction (which is cancel page loading). Which goes to the point that Escape isn't a good option for closing tooltips.

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).

[mbgower]

The custom tooltips on this page don't have parity with native tooltips

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 Ctrl. I hadn't even reached discussions on conflicts, but that is obviously a challenge.

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

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.

[clshortfuse]

But native html tooltips (i.e, user agent behaviour on title) do not get exposed by keyboard, so we are treating them differently.

The point is that native html tooltip can be dismissed with Ctrl and pressing Escape on it will trigger side-effects. The custom tooltip in the page does not dismiss like a native tooltip.

Thanks @accdc for mentioning the 'stop speech' feature of most screenreaders from Ctrl. I hadn't even reached discussions on conflicts, but that is obviously a challenge.

I already addressed this, previously.

I'm not fully advocating for Ctrl. It's not a perfect solution. Ctrl will stop reading on NVDA. (Though to be fair, so will Esc)

https://github.com/w3c/aria-practices/issues/2538#issuecomment-1315526294

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.

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.

Which I addressed in the first comment:

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 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 Ctrl will not close the popup. Pressing Esc will.

Now if we move to an application that is not open we get a real, native tooltip. It's short-text and small. Ctrl will close this, because it's a tooltip. ESC will not close this:

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.

[mbgower]

I'm not fully advocating for Ctrl. It's not a perfect solution. Ctrl will stop reading on NVDA. (Though to be fair, so will Esc)

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!

[clshortfuse]

@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.

[clshortfuse]

From Microsoft's usability study (link pulled from the vscode issue that mentioned this):

https://www.youtube.com/watch?v=lb0_v7D4kbs&t=1548s

"So escape is not a very good key to dismiss tooltips"

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed tooltips closing with Escape is an irregular UX practice.

The full IRC log of that discussion

<jugglinmike> subtopic: tooltips closing with Escape is an irregular UX practice
<jugglinmike> github: https://github.com/w3c/aria-practices/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

[mcking65]

@clshortfuse

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:

• How likely are users to believe that one kind of transient content should behave differently from another? E.g., dialogs, menus, selects, toasts, tooltips, and a variety of hover effects could all be thought of as transient by users.
• If a user learns they can dismiss a fly out menu with escape, are they likely to try Escape when something else, like a tooltip, flies out?
• What usability effects are likely if some elements that pop up or fly out can be dismissed with Escape and dismissing others requires a different key?

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?

[mbgower]

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.

[clshortfuse]

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 Esc, specifically, is forcing us to analyze tooltips more generally. I took a second look at the points in the conversation and have been working on other controls as well since then. (I'm currently working on combobox and expect to file an issue related to keyboard interactions later on 😅.) But I had to try to put in more words what works and what doesn't with user expectations and UI. I lean on a couple of factors (forgive me if I don't know the right UX nomenclature):

1. Symmetry/Reciprocity/Consistency of user interactions. For instance, if a tooltip is spawned with a mouseover, it's removed with the mouseout. Toggled by touchstart: closed by touchcancel. Spawned due to focus via keyboard event: closed via blur.

2. Level of user commitment. I consider mouseover as a low commitment. Users don't expect they are commiting to an action by just hovering. The same applies with keyboard focus. Simply tabbing to an element is understood as passive operation. (* Devil's Advocate: long hover (~500ms) do perform actions like open a cascading menu.)

3. Changes to visuals (contrasting). If something happens far from the general focus, users don't expect to be actively interacting with them (eg: toasts or notifications). If something happens close to where their focus is, they feel they are related (popup/non-modal popup). If something happens in the center of the screen and actively dims the background (dialog) then they feel they were brought into a new context. Essentially, it's the level of contrast between the state they were in and the state they are in after the popup action.

I see Esc has an expectation of hard commitment which doesn't match the level of contrast applied. It's also not consistent with the user's level of commitment. A user click of a button (hard commitment) can be matched with an Escape keypress. This is inline with what @smhigley calls "toggle-tips". Though, there are exceptions when the contrast is so high that it feels warranted. For example "rich" tooltips (which to me are non-modal dialogs) close with escape. But that lends to the popup not having been expected for so little of a user interaction (mouse over) which feels more like an alert (eg: Your password is incorrect).

I took a second look at different UIs and see there's also a level of expectation of "overlayed" content. For example, role=accordion and role=disclosure add content related to other elements, but there's little expectation for Esc to close them, because they don't actually cover content. Combobox, menus, and dialogs all have the Escape key well established because they add a new layer (are popups).

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 Esc is navigable with arrow keys (pressing up). It leads to Esc being used for interactive content.

I did notice the guidelines state:

Tooltip widgets do not receive focus. A hover that contains focusable elements can be made using a non-modal dialog.

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 <dfn title> or <abbr title>, but for tools.

---

(TL;DR):

Tooltips should be non-interactive and not "rich" in anyway. They should be small, unobtrusive, suggestive (unimportant) and dismissable with Ctrl. They should be close to the native <abbr title> <dfn title> types.

More complex or important popups would be non-modal dialog which are closed by Esc. The ability for non-modal dialogs to display focus is not required.

Authors should apply sufficient differing visually styling to differentiate between tooltips and non-modal dialogs to avoid user confusion between the two.

---

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 ctrl aspect. I personally find the "toggletip" concept she encourages (which may be a non-modal dialog) most interesting and if guidelines could better flush out when to choose between tooltip/toggletip, it'd be easier to not feel forced to use tooltip. That might mean more non-modal dialog examples, but I couldn't find what role @smhigley suggests we use for toggletips.

[mbgower]

@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:

• the trigger is its own navigable UI element which must be be consciously acted on by a user (activated, not hovered) to show the temporarily disclosed information
• the disclosed information can take focus and can contain its own actionable children

Note that a toggletip's disclosed child, while the trigger still has focus, can be closed by toggling the trigger again. Esc (or whatever key is assigned to dismiss) is unnecessary to employ until the user navigates to the child component. Carbon retains Esc regardless. (There are a bunch of corrections to the documentation that are in the works; I've opened issues against their documentation for both tooltip and toggletip.)

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?)

role=disclosure add content related to other elements, but there's little expectation for Esc to close them, because they don't actually cover content.

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.

I personally find the "toggletip" concept she encourages (which may be a non-modal dialog) most interesting

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.