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!