1.4.13 Content on Hover or Focus - dismissable and persistent clarification

[smhigley]

In attempting to make good tooltip examples and talking with developers about tooltips and 1.4.13, I've run across one blocking issue with the dismissable requirement and one suggestion for persistence:

Dismissable

The only dismissable example provided in the Understanding section mentions using the escape key (or any other keyboard interaction) to dismiss content on hover. However this has certain blocking technical limitations, since the element capturing the keyboard event isn't likely to be the same element displaying the popup on pointer hover. It is possible to have an escape event listener on the body tag, but this will fail for tooltips appearing within modals or tooltips sharing a page with any other component that uses escape (e.g. menus, comboboxes, etc.) which may happen to have keyboard focus. At worst, a user attempting to dismiss a tooltip within a modal will not be able to do so without dismissing the entire modal.

The only practical solution I've found has been to include a close button on the tooltip, but this violates the requirement to dismiss without pointer movement (related to #409). It's possible to prevent the tooltip from re-appearing on hover after actively closing it, which seems to meet the spirit of the criterion, but still violates the text.

Would it be possible to either modify the pointer dismissable requirement to allow that technique, or provide an alternate example technique that works for pointer users?

Persistent

This came up when evaluating how 1.4.13 applies to desktop tooltips through EN 301 549. Windows has had (very long) timeouts built into desktop tooltips for a good while, and adding a Settings option to adjust or remove tooltip timeouts was suggested for this criterion. This still technically violates 1.4.13, though it seems internally consistent with 2.2.1/Timing Adjustable. Would there be any interest in modifying the Persistent requirement to either refer to Timing Adjustable or allow a user-adjustable timeout?

[JAWS-test]

Would it be possible to either modify the pointer dismissable requirement to allow that technique, or provide an alternate example technique that works for pointer users?

First I would like to know if it is possible to design the Working Example of SCR39 so that the page contains multiple tooltips and other elements that are closed with ESC, and tooltips within pop-ups - and still work.

[alastc]

If esc is generally caught and dismisses 'open' things, that is likely to be a good thing except in the case of nested items.

Having a dismissable item nested within another dismissable item probably isn't a good idea!

Another avenue is to use the exception within dismissable: "unless the additional content ... does not obscure or replace other content". I.e. if the tooltip is reliably in an area that does not cover other content, then it does not need to be dismissable.

For the persistent point, it is applying to all sorts of pop-overs, and in the case of large boxes of content I don't think many of the LV users would want it to time out. Browser-native tooltips and explicitely excepted, so it is only small custom tooltips that fall into this area.

We can ask, but I suspect the LV folk would rather hover wasn't used for this sort of functionality, it is difficult to use when magnified. Given the popularity of touch-screen usage, it seemed likely that click/tap would be a better approach all-around.

[JAWS-test]

Having a dismissable item nested within another dismissable item probably isn't a good idea!

I wonder if it is possible to close with ESC only the element that was shown by hover depending on the keyboard focus and current mouse position - or to close with ESC only the pop-up if no nested elements are shown by focus or hover. If a content is displayed via hover or keyboard focus, ESC would always close this element first and the pop-up would be closed at the second ESC.

[smhigley]

@alastc I think perhaps I'm perhaps reading too much into your recommendation -- my first read of this:

If esc is generally caught and dismisses 'open' things, that is likely to be a good thing except in the case of nested items.

Having a dismissable item nested within another dismissable item probably isn't a good idea!

is that it's an acceptable side effect of 1.4.13 be to forbid any content on hover or focus within a modal. While I personally dislike tooltips and other hover/focus popups and would be OK with forbidding them outright, it would be quite a hard sell to tell all product teams that they can never put a tooltip inside a modal. Is there another way to meet 1.4.13 that allows tooltips in modals without relying on not overlapping other content?

From a practical perspective, I've found the "does not obscure or replace other content" exception almost never works, since at some screen size between desktop and mobile it's likely that a tooltip, even a short one, will overlap something as the page reflows. Especially when designing reusable tooltips, it's impossible to know whether one will be used either within a modal or in a way that overlaps other content (particularly at small screen sizes).

To the "it's ok to close all open things" point -- I don't dislike the theoretical user experience, and it could be technically feasible if the user's focus is on an element without a popup. I run into some issues in specific cases that still seem blocking, since the web author doesn't have control over where the user's focus may be at any given point.

Any component that captures and uses escape should stop propagation of escape key presses for the same reason I raised the issue -- a combobox won't know if it's on a static page or within a modal, so it needs to always .stopPropagation of escape key events to prevent unintended side effects. So if a user is in a situation where they've clicked into a combobox (or any other component with escape behavior) and then go explore a tooltip somewhere else, escape would not be able to close the tooltip; it would be consumed by the combo and would never reach the body tag. My current impression is that this means a hover-triggered popup will not be able to rely on escape not only within modals, but also when sharing a page with components like comboboxes, menus, etc. that may use escape. Though please let me know if I'm missing anything that would enable a generic dismissable tooltip (or other popup) on hover, or if the intent is really as prohibitive as it seems (to be fair, I'd love to get rid of all hover content, full stop 😄).

I definitely get the reluctance for timing adjustable pop-overs, it does seem like a benefit in only a small subset of cases, and definitely more feasible to have user-adjustable timing settings in an OS than in a web app. The browser-native tooltip is actually an interesting case study for this though -- I know web content authors are exempt when it comes to title attributes, but are browser vendors on the hook? That is, are all the major browsers currently in violation of 1.4.13 (or C.11.1.4.13) through EN 301 549?

[JAWS-test]

I have created an example where the first ESC closes all tooltips and the second ESC closes the pop-up. If no tooltips are open, the first ESC closes the pop-up. The example shows that it is not a problem to evaluate ESC contextually.

[JAWS-test]

In the meantime, I also think that SC is difficult to implement in practice:

• Hover over an element in an iFrame: ESC key doesn't work if keyboard focus is not in the iFrame
• Hover over an element: ESC key does not work if focus is not on the page but on an element of the browser (or even in another application)
• Hover over an element and keyboard focus on another element: which of the two displayed contents should ESC close?

[smhigley]

Is there any update on this? This requirement is still causing a non-trivial amount of effort put into both investigating whether it is achievable from a technical perspective in various contexts, and what the options are if and when it is not.

Specifically, these are the cases we have found where dismissing hovered pointers via escape is not viable:

• content within iframes
• content within modals, where the modal is a component from a UI framework
• content that shares a page with a component that traps keyboard events, such as a toolbar with tooltips above an in-browser code editor
• developing UI frameworks that build reusable components that are not aware of their context (in the case of components with tooltips), or their content (in the case of modals)
• any product that uses modals, slidepanes, or tooltips from a UI framework

I also conducted a small-scale usability study with 12 participants, and found that well-placed close buttons were preferable to the escape or control keys for dismissing tooltips by low vision users. Most participants were using magnification at around 800%.

Right now, my personal recommendation is that teams should not invest time into attempting to follow the pointer dismissal specifics, but of course that causes issues when WCAG is a legal requirement. Is there any chance this will be fixed in 2.2, or get an updated Understanding doc with more viable possibilities?

For reference, this is the tooltip close button design that performed better than keyboard dismissal in the usability study:

[alastc]

Hi @smhigley,

Thank you, that's very well conveyed. (Arg, I read that and it sounds sarcastic, it is sincere, I just can't think of another way to say: awesome bug report, it is really clear!)

I'm going to ask the Low Vision Task Force for comment (and @steverep if he is around).

One thing that jumps out to me is that “without moving pointer hover or keyboard focus” was intended to mean: move away from the trigger.

I think that might have been ‘refined out’ at some stage for clarity. Or perhaps it was that a close button within the target would be very complex, as you’d have to trigger on entry to the target only.

With that meaning, the solution where the ‘close’ button overlaps with the target would work I think?

[RobGallo]

One thing that needs to happen with this entire discussion is the complete abandonment of the escape key as a tooltip dismissal mechanism. It's folly.

A blind or low vision user cannot be expected to know at all times if a tooltip is present or not. Thus the behavior of the escape key will, in practice, be unpredictable. Since the escape key is often a key with consequences, it is not an acceptable user experience to link a possibly unknowable behavior to such a key.

[alastc]

A blind or low vision user cannot be expected to know at all times if a tooltip is present or not.

The requirement that there is a mechanism to close pop-over content came from low-vision users. (If someone is completely blind there are generally different problems with tooltips.)

Esc key is one method, and tooltips are a sub-set of the possible pop-over content. There are other methods, and there are other types of content which might suit different methods.

Take the tooltips above this edit box (aA, B, i) for example, they have tooltips that reliably do not cover other content, so no need for another mechanism.

I do talk the point that the UX for low vision users can be tricky, but it is something asked for because the UX of pop-over content is worse.

We took mention of the close button out because it seemed to difficult to do, but if @smhigley created and tested it, perhaps that is a better solution for that type of content.

[RobGallo]

My point is that the escape key is not a useable method to dismiss any non-modal or non-focused content. WCAG needs to be extremely clear about that. And regardless if LV users asked for the criterion, the negative impact of using escape on blind users will be the same.

[alastc]

A typical instance we get in audits is a mega-menu, and in that case using esc is a reasonable method. It isn't very discoverable, but if you need it, it is there.

It doesn't generally affect screenreaders because it either isn't triggered, or is triggered by focus and esc should put your back on the opening element.

[RobGallo]

In the case you describe, the menu sounds like 1. It has focus 2. It is intended that a user interact with it Neither of which is true of a non-modal, non-focusable overlay. In the case where the user is interacting with an element with focus directly, escape is an acceptable solution. But those situations are not the ones we’re talking about. Escape is never okay for any content under the tooltip umbrella: non-modal, non-focusable popups or overlays. If you’re saying that the menu is triggered by hover, then I’ll say, and rightly so, that a mouse hover should never trigger a focus change, or the need for a focus change. That is an unexpected change of focus, which is disorienting for screen reader users.

[smhigley]

@alastc thanks for the response! Do you think updated wording to allow for overlaid close buttons could make it into 2.2, at least if it's not controversial?

One other piece of clarification: would the requirement be that the close button overlays the hit target, even if the boundaries of the hit target aren't visible? E.g. in the case of links or borderless buttons, would this still pass?

I can foresee designers griping a bit about the specificity of requiring the close button to overlap the target vs. some measure of proximity or ergonomics, but this does at least give a path forward, so I'll take it 😁.

Thanks again!

[alastc]

@smhigley I'm not sure if it would be better to update 2.1 (errata) or adjust in 2.2, we'd have backwards incompatibility issues with just adjusting in 2.2. We'll discuss that.

Also, where I said "move away from the target" above, I had meant the trigger, i.e. the element that triggers the pop-over content. (I was thinking in terms of mouse targets, sorry.)

The overlapping example fulfils that either way, but just to be clear about where the requirement came from.

[smhigley]

@alastc I had meant the element that triggers the pop-over as well 😄. To add some visuals, would the tooltip in the first screenshot below pass?:

This second screenshot shows the same link/tooltip, but with a background color to demonstrate that the close button does intersect with the boundaries of the link element, even if it is not visually apparent in the first screenshot:

[joe-watkins]

Since sub-menus are clearly called out in the understanding document:

A typical instance we get in audits is a mega-menu, and in that case using esc is a reasonable method. It isn't very discoverable, but if you need it, it is there.

1. Can anyone provide a single accessible example of this recommended approach in the wild where the mega menu / or site navigation / sub-menu, which has hover as one of the events to show/hide sub-menu items, can be closed with the escape key? This should of course be keyboard accessible too!

2. Does this ARIA menu fail 1.4.13 because sub-menu items can't be dismissed with escape key as it obscures content beneath it?
   https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/menubar-1.html

3. Can anyone provide an alternative mechanism for closing sub-menu items that isn't the escape key and that doesn't require moving the mouse?

4. A dialog is opened and within it has a widget that appears on hover which obscures content. When escape is pressed, what should happen? If the widget is to close but not the dialog, imagine the amount JS that is needed to try and manage this logic. For every esc keyup you'd need to check things being hovered with the mouse and their state? wow!

@smhigley It's my interpretation that if the user has to move the mouse to dismiss something it would be a failure. So having to move the mouse to click on a close control would fail.

Failure to make content dismissable without moving pointer hover or keyboard focus

[idoros]

close button does intersect with the boundaries of the link element

Notice that having such intersection means that in some cases after clicking the close button, the mouse will be over the tooltip anchor again and might trigger it immediately or on move. Tooltip delay helps, but still, even moving the mouse for a bit and then keeping it in the boundaries will definitely pop the tooltip again.

Why is the intersection important?

Also would you expect the close button to be tabbable? if a user tab into the link and the tooltip opens, would another tab move to focus the close button?

--- edit ---

I now see that @alastc wrote that the close button has been removed from the spec: #409 (comment)
But this was over a year ago and comments here are recent. so not sure if this is relevant.