Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft tooltip design pattern #128

Open
mcking65 opened this Issue Oct 16, 2016 · 23 comments

Comments

@mcking65
Copy link
Contributor

mcking65 commented Oct 16, 2016

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 #85?

@mcking65 mcking65 added this to the 1.1 PR milestone Oct 16, 2016

@mcking65 mcking65 self-assigned this Dec 14, 2016

@mcking65

This comment has been minimized.

Copy link
Contributor Author

mcking65 commented Dec 14, 2016

Fixed editorial issues in commit b1407a8.

@mcking65 mcking65 added pattern and removed needs edits labels Jan 19, 2017

@wendyabc

This comment has been minimized.

Copy link

wendyabc commented Feb 4, 2017

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

@mcking65

This comment has been minimized.

Copy link
Contributor Author

mcking65 commented Feb 4, 2017

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

@paulwaitehomeoffice

This comment has been minimized.

Copy link

paulwaitehomeoffice commented Feb 28, 2017

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

This comment has been minimized.

Copy link
Contributor

carmacleod commented Mar 30, 2017

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

@carmacleod

This comment has been minimized.

Copy link
Contributor

carmacleod commented Mar 30, 2017

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 F2, or maybe Shift+F1, 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

This comment has been minimized.

Copy link
Contributor

carmacleod commented Mar 30, 2017

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

This comment has been minimized.

Copy link
Contributor

ZoeBijl commented May 8, 2017

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.

@carmacleod

This comment has been minimized.

Copy link
Contributor

carmacleod commented May 23, 2017

Regarding having ESC close the tooltip, if a tooltip is shown (and focused) when the user types a keyboard shortcut (such as F1, F2, or Shift+F1), then ESC can be used to hide it.

Alternatively, perhaps any Tooltip that is optionally shown/focused on a keyboard shortcut falls under the jurisdiction of the Tooltip dialog pattern (issue #85), even if it only contains text?

@jnurthen

This comment has been minimized.

Copy link
Contributor

jnurthen commented May 23, 2017

@carmacleod

This comment has been minimized.

Copy link
Contributor

carmacleod commented May 23, 2017

Having ESC close the tooltip allows you to close it if it is distracting.
For example, if there were a really big tooltip attached to something which
obscures some other information you may want to see when filling in a form
field.

Agreed that that would be a nice thing to have. Note that the ESC key would go to the trigger element in that case, and not the tooltip, because according to the spec, "Tooltip widgets do not receive focus."

@steverep

This comment has been minimized.

Copy link
Member

steverep commented Aug 1, 2017

The below note seems to violate a success criterion being proposed for WCAG 2.1:

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.

See w3c/wcag21#75. There are accessibility reasons for the tooltip to persist while the tooltip itself has mouse hover.

@guyhickling

This comment has been minimized.

Copy link

guyhickling commented Aug 15, 2017

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 above would be true where an item of content must be clicked on by mouse users to reveal the tooltip text; here the keyboard user would need an F1 or similar shortcut as suggested.

But most tooltips I see involve a separate button beside the content, usually with an icon on them such as a ? character, or an I for information, or even the word Help. Depending on what interactivity the designers have chosen the keyboard user either focusses on it using the Tab key to reveal the tooltip, or they must press Enter or spacebar to reveal it. This kind of tooltip should be allowed for in this SC (I believe they can still be considered tooltips, as they perform the same function and behave the same way, they are just tooltips on the dedicated button instead of on the content itself).

These cases use the element (or they should though many developers use an instead, but that's another story). Whether or the keyboard interaction is defined in the HTML spec, and keyboard users know how to operate buttons and links (pressing Enter works for both) so there is no need to provide extra info for it.

@carmacleod

This comment has been minimized.

Copy link
Contributor

carmacleod commented Aug 15, 2017

Our use case is a code editor. Users can open a tooltip anywhere in the editor, to show the comment for a method or variable, the detailed text of a compiler error or warning, the details of a breakpoint for the current line, etc. Mouse users can see these tooltips by simply hovering over the function/variable name, error/warning indicator, or breakpoint annotation. Keyboard users need to navigate to the "trigger location" using the arrow keys, and then they can optionally open the tooltip by pressing F2.

Note that the editor itself is the "trigger element", but it has focus the whole time, so focusIn cannot trigger the tooltip(s). It is the caret location that determines which tooltip is shown. It does not make sense to open them automatically when the caret reaches the intended trigger location because that gets incredibly annoying.

If you are familiar at all with the Eclipse IDE, this is the way their code editor works. We used the same technique in our code editor because our Web IDE (Orion) was mostly written by Eclipse devs. :)

An additional "quirk" of this technique is that a mouse user can hover to open a tooltip, and then, if they want it to take focus for whatever reason (some of the tooltips have buttons or links in them, which can be activated with keyboard or mouse), they simply type F2 and we give the tooltip focus. Esc closes it.

One could argue that these are "dialog tooltips" and not "tooltips", or maybe they are a different beast altogether, but the typical mouse experience feels exactly like a tooltip, so we tried to keep the keyboard experience as close as possible.

I could imagine an map or some other complex visualization working in a similar manner - the map has focus, the keyboard user navigates with arrow keys, and any time they want more info on the current location, they type F2 to get a tooltip.

@Yaffle

This comment has been minimized.

Copy link

Yaffle commented Dec 18, 2017

the title attributes sets the "aria-labelledby", not "aria-describedby", right?
So is there cases for tooltips when aria-labelledby should be used - like for a "toolbar button" (icon+tooltip) ?

@craigkovatch

This comment has been minimized.

Copy link

craigkovatch commented Jun 5, 2018

I would like to see guidance about whether elements with role=tooltip are intended to contain text-only content, i.e. functionally equivalent to the title attribute.

@carmacleod

This comment has been minimized.

Copy link
Contributor

carmacleod commented Jun 5, 2018

I would like to see guidance about whether elements with role=tooltip are intended to contain text-only content, i.e. functionally equivalent to the title attribute.

I believe the tooltip pattern is intended to contain text-only content,
and the tooltip dialog pattern is intended for tooltips with interactive children.

@mcking65 can correct me if I am wrong.
If this is correct, then yes, it should be explicitly stated in the pattern doc.

Please see #85 for discussion on the tooltip dialog pattern.

@craigkovatch

This comment has been minimized.

Copy link

craigkovatch commented Jun 7, 2018

I believe the tooltip pattern is intended to contain text-only content,
and the tooltip dialog pattern is intended for tooltips with interactive children.

Thanks @carmacleod! What about formatted text, e.g. bold or italics? Is the differentiating factor "interactivity", or is it closer to "anything that's not a plain string"?

@carmacleod

This comment has been minimized.

Copy link
Contributor

carmacleod commented Jun 11, 2018

@craigkovatch Interactivity is the defining factor. Custom tooltips can contain bold, italics, underline, an icon, whatever, as long as you make sure to put the text equivalent of all the stuff in an aria-describedby on the trigger element.

As soon as you add a button or a link or some other interactive thing, then you need to be marking up a "tooltip dialog".

@patrickhlauke

This comment has been minimized.

Copy link
Member

patrickhlauke commented Jun 11, 2018

i'd suggest, nonetheless, that you should avoid putting complex structured text content (e.g. with headings, bullet lists, etc) in a tooltip, as this will all be announced "in a oner" by AT if it's just associated via aria-describedby. so for anything mildly complex/structured, it'd be best for authors to go for a dialog-style tooltip with an explicit close control, i'd say.

@carmacleod

This comment has been minimized.

Copy link
Contributor

carmacleod commented Jun 11, 2018

Excellent point @patrickhlauke. Agree completely. We'll want that advice added as a note in the tooltip pattern doc. :)

@carmacleod

This comment has been minimized.

Copy link
Contributor

carmacleod commented Jun 11, 2018

So is there cases for tooltips when aria-labelledby should be used - like for a "toolbar button" (icon+tooltip) ?

Good point @Yaffle. A "toolbar button" (or any icon that does not have a visible label) does need a label.
The author can use aria-label or aria-labelledby, or alt if they're using an <img>, or even title, to give the icon its label.

The author would also want to give the icon a tooltip (using either title or a custom tooltip) so that sighted folks can figure out what the icon is.

So if the tooltip text and the label are the same (which would be the typical case), then I would think that yes, you would use aria-labelledby to point to the custom tooltip text instead of aria-describedby.

@waterplea

This comment has been minimized.

Copy link

waterplea commented Dec 27, 2018

Having modal tooltip just to display links to more info is a bit harsh. We have tooltips icons inside the input visually (kinda like X button to clear input) — how would I go about tooltips with links? Moving focus from input to tooltip for links and locking it there is clearly not an option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.