Draft tooltip design pattern

[mcking65]

The tooltip design pattern is at:
http://w3c.github.io/aria-practices/#tooltip

It is largely complete. Things to fix include:

• Redundant wording and incomplete sentences in the description.
• The keyboard section needs revisions to bring it inline with APG editorial requirements.
• The states and properties section needs revisions to bring it inline with APG editorial requirements.
• Remove external links from example section.
  page.

Open questions:

• Should there be any guidance about using tooltip verses title attribute.
• The introduction links to the non-modal dialog section. Should that instead be to the tooltip dialog pattern called for by issue Draft tooltip dialog design pattern #85?

[mcking65]

Fixed editorial issues in commit b1407a8.

[wendyabc]

Yes, please do include guidance on using tooltip vs title attribute.

[mcking65]

@wendyabc, do you have some specific issues in mind that such guidance should address?

[paulwaitehomeoffice]

This may already be in hand, but the current wording of the keyboard interactions reads as slightly ambiguous to me:

A tooltip is a popup that displays information related to an element when the element receives keyboard focus or the mouse hovers over it. It typically appears after a small delay and disappears when Escape is pressed or on mouse out.
...
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.

Should pressing Escape always dismiss the tooltip, or only dismiss the tooltip if it was invoked when the trigger element received focus?

[carmacleod]

Yes, please link to the tooltip dialog pattern rather than the non-modal dialog section.

[carmacleod]

Regarding tooltip vs title: at present, I am not aware of any way for a sighted keyboard-only user to see the content of the title attribute (unless they are using an AT).
So, one advantage of using a tooltip is that the tooltip can be displayed for keyboard users, either by:

• automatically opening the tooltip when the element receives focus, or
• providing a keyboard shortcut, such as F1 or Shift+F1, or maybe F2 to open the tooltip for the focused element

The advantage of automatically opening the tooltip when the element receives focus is that this makes the tooltip very discoverable for keyboard users, but the (big) disadvantage is that keyboard power users very quickly become tired of them, even when there is a delay.

The (big) advantage of providing a keyboard shortcut to open the tooltip is that users can choose when they want more information. The disadvantages are:

• discoverability of the keystroke that will open the tooltip (standardization would really help here, but this info can be provided along with other accessibility tips and settings for the site)
• the developer needs to provide a visual affordance that there is a tooltip available for an element (note that AT users would not need an affordance, because the tooltip pattern explicitly requires the use of aria-describedby, which would count as the affordance in this case)

[carmacleod]

The first sentence of the tooltip pattern is:
"A tooltip is a popup that displays information related to an element when the element receives keyboard focus or the mouse hovers over it."
The previous comment discusses 2 ways that a tooltip can be displayed for keyboard users:

• automatically opening the tooltip when the element receives focus, or
• providing a keyboard shortcut, such as F1, Shift+F1, or F2, to open the tooltip for the focused element

So I think we should change that first sentence to something more like the following:
"A tooltip is a popup that displays information related to an element when the element receives keyboard focus or the mouse hovers over it, or when a focused element receives a specific keyboard shortcut to display the tooltip."

[ZoeBijl]

What exactly is the point of having esc close the tooltip if it appears on hover/focus? As it would close when the control that invoked it is no longer hovered or focused (as mentioned in the note under keyboard interaction).

Related thread on Twitter.