Possible conflict between role tooltip and WCAG 2.1 Success Criterion 1.4.13 Content on Hover or Focus

[LaurenceRLewis]

Issue 1:

ARIA:
https://www.w3.org/TR/wai-aria-practices-1.1/#tooltip

If the tooltip is invoked when the trigger element receives focus, then it is dismissed when it no longer has focus (onBlur). If the tooltip is invoked with mouseIn, then it is dismissed with on mouseOut.

WCAG 2.1
https://www.w3.org/TR/WCAG21/#content-on-hover-or-focus

If pointer hover can trigger the additional content, then the pointer can be moved over the additional content without the additional content disappearing.
The additional content remains visible until the hover or focus trigger is removed, the user dismisses it, or its information is no longer valid.

In the ARIA spec it is the triggering element (link/button) only that controls the show/hide of the tooltip content (additional content). This conflicts with the WCAG spec where focus needs to encompass the trigger and additional content.

Issue 2:

https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html

As I understand it role=tooltip does not allow active embedded elements, however, the WCAG 2.1 spec stats:

Provide a mechanism to easily dismiss the additional content, such as by pressing Escape or selecting a close button.

[css-meeting-bot]

The Working Group just discussed tooltips.

The full IRC log of that discussion

<jamesn> TOPIC: tooltips
<jamesn> https://github.com/w3c/aria-practices/wiki/August-6%2C-2018-Meeting#wcag-requirements-for-tooltip
<jamesn> https://github.com//issues/811
<jamesn> mk: ambiguity in the pattern is that the pointer needs to be able to be moved over the additional content without it disappearing
<jamesn> ... it would have been obvious to me that this should happen
<jamesn> hh: it is not always when there is interactive stuff in the tooltip
<jamesn> jn: reason is for zoom users
<jamesn> mk: do we need to make a simple edit to what is in the pattern
<jamesn> mk: Do we need to specify about the hover
<jamesn> hh: need to specify that need to add something to "If the tooltip is invoked with mouseIn, then it is dismissed with on mouseOut." about mouseOut unless focus moved over the tooltip
<jamesn> hh: we have made a statement about mouse behavior but WCAG states something different
<jamesn> mk: the 2nd part was for tooltips which include interactive elements... there is no reason for keyboard users to focus that tooltip... there is no reason to make it focusable.
<jamesn> Github: https://github.com//issues/811
<jamesn> siri: depends how much content there is in the tooltip... to allow the screen reader to read line by line in virtual mode we need to allow focus to move to the tooltip content.
<jamesn> mk: in that case want the dialog pattern
<jamesn> siri: dialog pattern some screen readers will be in application mode
<jamesn> mk: if want focus to move to it use dialog pattern - if don't use tooltip pattern
<jamesn> mk: Provide a mechanism to easily dismiss additional content
<jamesn> mk: the such as seems to describe a dialog not a tooltip
<jamesn> Evan: does the triggering element have anything to indicate it is a tooltip
<jamesn> ... maybe a next button
<jamesn> hh: what does role tooltip actually do other than exposing a tooltip role to the AAPI
<jamesn> mk: tooltip role doesn't seem that useful to me... can aria-described pointing to any other element... what would anything do to this
<jongund> have to go
<jamesn> hh: I would expect virtual focus to be able to go to it
<jamesn> siri: if keeping non modal dialog then tooltip means that whenever hover it content should appear just on focus
<jamesn> mk: can't think of a reason why non modal dialog wouldn't work
<jamesn> hh: need a shortcut to move focus to it
<jamesn> mk: one of these patterns where we don't have everything we need
<jamesn> mk: not sure what to do about that yet

[carmacleod]

hh: need a shortcut to move focus to it
mk: one of these patterns where we don't have everything we need

I humbly and hopefully suggest SHIFT+F1 as the standard shortcut to move focus to a tooltip or tooltip dialog. I suggest also that SHIFT+F1 can (optionally) open [and focus] the tooltip or tooltip dialog (i.e. "tooltip on demand") for any "focused thing that has a related tooltip or tooltip dialog".

Related:

• Draft tooltip dialog design pattern #85 (comment) (See Edit: at end of comment).
• Clarify the use of role=tooltip aria#979 (comment)

[jlukosky]

hh: need a shortcut to move focus to it
mk: one of these patterns where we don't have everything we need

I humbly and hopefully suggest SHIFT+F1 as the standard shortcut to move focus to a tooltip or tooltip dialog. I suggest also that SHIFT+F1 can (optionally) open [and focus] the tooltip or tooltip dialog (i.e. "tooltip on demand") for any "focused thing that has a related tooltip or tooltip dialog".

Related:

• #85 (comment) (See Edit: at end of comment).
• w3c/aria#979 (comment)

Carmacleod,

Since tooltips don't receive focus would your proposal be only for tooltip dialogs or are you proposing to make tooltips focusable?

[carmacleod]

@jlukosky

Since tooltips don't receive focus would your proposal be only for tooltip dialogs or are you proposing to make tooltips focusable?

Good question, and I don't have a good answer. :)

When I saw the meeting-bot comment containing tooltip discussion notes from the ARIA Working Group with "hh: need a shortcut to move focus to it", I simply wanted to make sure that if a shortcut is added to move focus to a tooltip (or tooltip dialog), then SHIFT+F1 is seriously considered for that shortcut.

Tooltips (either title attribute or custom) have been a multi-pronged accessibility problem for so long that maybe it's time for some off-the-wall changes to their UI (such as perhaps allowing them to take focus under certain conditions). ;)

Anyhow, I did not mean to go off-topic for this issue, which is about WCAG SC 1.4.13.

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed Tooltip conflict.

The full IRC log of that discussion

<MarkMccarthy> TOPIC: Tooltip conflict
<MarkMccarthy> mck: in summary - this is about specific language
<MarkMccarthy> mck: i think the issue is that our language doesn't say anything about mouse hovered on a tooltip; that we don't generally provide mouse guidance in APG patterns
<MarkMccarthy> mck: is this an actual conflict? should we change the wording? or say it's not an issue?
<MarkMccarthy> carmacleod: tooltip is REALLY complicated. mouse is integral to using tooltips, mostly, but depends. it's not something I've been easily able to resolve
<MarkMccarthy> Sarah_Higley: I'd be in favor of adding wording about mouse behavior for tooltips, becasue it's easy to get that wrong
<MarkMccarthy> mck: across most of WCAG we don't usually have mouse reqs, but for this specific instance, there's issues around pointers etc.
<MarkMccarthy> mck: that's an exception to the norm right?
<MarkMccarthy> carmacleod: yeah
<Jemma> git --help
<MarkMccarthy> github:
<MarkMccarthy> github: https://github.com//issues/811
<MarkMccarthy> mck: so what i'm hearing is we want to describe accessibility related pointer requirements in the APG pattern
<MarkMccarthy> carmacleod: i think so
<MarkMccarthy> Sarah_Higley: yes, definitely
<MarkMccarthy> Sarah_Higley: the difficulty is how to describe it, certain interactions, etc. but that can be part of another discussion
<MarkMccarthy> mck: i'd really welcome someone to draft some changes to the pattern in a PR, if someone can
<MarkMccarthy> Sarah_Higley: I can, i've been writing about tooltips lately. i think there's some stuff about dismissal that is controversial that'd be worth discussing before a PR
<MarkMccarthy> mck: a draft PR can contain anything, even if it'll go down in flames [laughs]
<MarkMccarthy> Sarah_Higley: okay
<MarkMccarthy> carmacleod: or add stuff to the issue before ready for the PR
<MarkMccarthy> group: thanks Sarah_Higley
<MarkMccarthy> Sarah_Higley: I planned on opening an issue anyway, so let's just go all in!

[smhigley]

Based on a mix of discussion and opinion, here are the additions to the APG tooltip pattern I would suggest based on this issue. For more potentially controversial or opinion-based recommendations, I have added the prefix "(opinion)".

Pointer Interaction:

• The tooltip remains open when moving the mouse from the triggering element to the tooltip element.
• (opinion) To benefit users with mobility impairments and to aid in easily moving the mouse between the trigger and the tooltip, there is a short delay between the mouseout event and the tooltip disappearing.
• (opinion) Pointer users may dismiss the tooltip by selecting a close button, after which the tooltip will not reappear on hover. The close button supplements keyboard escape behavior, so does not need to receive keyboard focus.

That last one is probably the most touchy, so I'll expand on the reasons for it:

Escape is not always a feasible way of dismissing a tooltip when focus is not on the triggering element. If the tooltip exists within a dialog, or focus happens to be on an element like a combobox or menu button, pressing escape will be handled by the dialog/menu button/combobox. Escape will not only not dismiss the tooltip, but will also cause undesired side effects (e.g. you try to dismiss a tooltip but end up closing the entire dialog).

In addition to the practical limitations, it seems more user-friendly to provide a pointer-based method of dismissing tooltips. Since a close button would be solely for the benefit of pointer users, the simplest approach would likely be to remove it from the tab order and not treat it as interactive tooltip content that would need a separate keyboard shortcut.

If it makes more sense to move forward with the first, or first and second recommendations and table the third as out of scope, I'm definitely open to that too :).

[JAWS-test]

I have no problem with a close button for pointer users. But

• If ESC closes the entire dialog, this also applies to keyboard users who cannot reach and operate the button. This means that ESC should be implemented in such a way that it closes only the tooltip as long as the triggering element has the focus. To close the dialog, you would have to press ESC twice. If the triggering element has no more focus, the tooltip will close automatically and 1x ESC will close the dialog.
• If ESC is pressed or the close button is activated, the tooltip should only be closed for this time and should not be deactivated permanently. In your example https://codepen.io/smhigley/pen/KjoerX, the tooltip is permanently closed when I press ESC and it will not be displayed again when focus the element. If I press the close button, it will be displayed again.

Also the SVG graphic of your delete button needs a focusable=false, otherwise it gets the focus invisibly in IE 11 - which also leads to a wrong output in the screenreader because the SVG has aria-hidden

[JAWS-test]

In Edge, closing the tooltips with ESC does not work and in Firefox ESR, the tooltip is immediately hidden again at the Delete button on mouseover.

And your tooltips don't look nice in High Contrast Mode: missing border and triangle becomes block. The "x" to close the tooltip is a little near to its border

Firefox ESR displays 2 focus frames. The browser's focus frame is much larger than the element itself.

[smhigley]

@JAWS-test thanks for your comments, I'll do my best to address them in order:

• The concern with escape does not apply to keyboard users; it is solely an issue with using escape as the only means to dismiss a tooltip triggered by mouse hover. When a tooltip is triggered by a focus event, the triggering element can capture and handle escape key presses, thus preventing them from having undesired side effects. However, if the tooltip is triggered through hover, then the element that receives the escape keyboard event could be anything at all -- this is where the possibility of unintended consequences comes in.
• If a close button is used as a method of dismissal for pointer users, the dismissal would need to be at least semi-permanent to meet the spirit of 1.4.13's dismissible requirement. Imagine a ZoomText user navigating their cursor and field of view over the tooltip to dismiss it, only to re-center their view and have it pop up again. Perhaps one way around this would be to have the close button on the triggering control (I believe this was suggested some time ago in a different issue), but I haven't seen that pattern in the wild.
• I'm not sure why the codepen came up, but it is not at all related to this issue, or intended as a mock for the APG. It's explicitly not production-ready, and you've definitely hit on some good ways it could be improved. The code is open source, and the web could certainly use more accessible production-ready tooltips if you wanted to take it and run with it.

[JAWS-test]

@smhigley:

The concern with escape does not apply to keyboard users

I understand your argument. However, it only applies if the application has been implemented correctly. I've already seen enough examples where the ESC key closed the entire pop-up, although the focus was on an element inside the pop-up that is closed with ESC.

the dismissal would need to be at least semi-permanent to meet the spirit of 1.4.13

I agree with you. I had only seen the opposite behavior in your example: re-display for mouse users, but not for keyboard users. But the exciting question is how to do this semi-permanently, not permanently. Unfortunately I have no idea.

I'm not sure why the codepen came up

I'm sorry. I knew your page and thought that your example should serve as a template for APG because it deals with exactly the same questions. That's why I had a closer look.

[JAWS-test]

The close button should not be inside the tooltip. It can be marked with aria-hidden=true, but the attribute will be ignored if it is referenced by aria-labelledby or aria-describedby. In JAWS, for example, the close button in the tooltip is output with Firefox and IE 11, but not with Chrome. See: FreedomScientific/standards-support#251

[smhigley]

@JAWS-test

I understand your argument. However, it only applies if the application has been implemented correctly. [...]

The APG generally does not exclude or recommend against techniques solely because they have the potential to be misused. However, if you think that escape should never be the mechanism for dismissing tooltips, it might be better to raise that issue against WCAG, since escape is explicitly mentioned.

The close button should not be inside the tooltip. It can be marked with aria-hidden=true, but the attribute will be ignored if it is referenced by aria-labelledby or aria-describedby.

Unless the close button itself is directly referenced by aria-labelledby or aria-describedby, it should not be included in the name or description: https://w3c.github.io/accname/#step2A. It would also be simple to point aria-labelledby or aria-describedby to an element containing only the tooltip text, while still keeping the button visually within the tooltip. There may be other reasons to consider different close button positions, but this doesn't seem to be one of them.

Hope that helps!

[jlukosky]

@smhigley:

• The tooltip remains open when moving the mouse from the triggering element to the tooltip element.

Would you be opposed to rewording this as
"The tooltip remains open when moving the mouse between the triggering element and the tooltip element."?

I've seen at least one implementation that lets the user mouse over the tooltip but not back to the trigger without dismissing the tooltip.