Aria-practices: Draft tooltip dialog design pattern

[mcking65]

When working on this issue, there is some old content that may be useful in the file aria-practices-DeletedSectionsArchive.html.
The relevant section can be seen here:
https://rawgit.com/w3c/aria-practices/master/aria-practices-DeletedSectionsArchive.html#dialog_tooltip

[carmacleod]

The first 2 sentences of the old version of this pattern are:
"A tooltip dialog is a modal dialog that is rendered near the invoking element and visually connected via a cartoon bubble-like protrusion. It is displayed when the mouse passes over or rests on that element."

For the first sentence, I prefer that we don't require the "cartoon bubble-like protrusion" and instead, make that just one example of how a tooltip dialog can be visually connected. For example, the sentence could read, "A tooltip dialog is a modal dialog that is rendered near the invoking element and is visually connected, usually via a cartoon bubble-like protrusion."
The reason for this is that we use tooltip dialogs to show coding errors in our code editor, and when they open they touch the red wavy underline in the code, so they are visually connected, without the cartoon bubble-like protrusion.

More importantly, it is the second sentence that needs more thought, because it currently does not include any mention of invoking tooltip dialogs via the keyboard (it only mentions mouse).
In our code editor's case, the user can use the F2 key to open and focus (or simply focus, if it's already open via mouse hover) a tooltip dialog that contains relevant information for the current caret position in the code (which could be a description of the error/warning with a possible "fix it" button, or it could be a code comment, or "to do" item, or a breakpoint in the code, etc).
So, I want to make it clear that tooltip dialogs need to be available to keyboard users with some kind of keystroke. Perhaps that second sentence could be something like:
"It is displayed when the mouse passes over or rests on that element, or when the user types a specific keyboard shortcut when the element has focus."

[Edit: We changed the keyboard shortcut that opens/focuses our tooltips and tooltip dialogs to Shift+F1, which is more commonly used for "Popup tooltip for currently focused control" or "Show context sensitive help" according to the [Table of Keyboard Shortcuts on Wikipedia](https://en.wikipedia.org/wiki/Table_of_keyboard_shortcuts). We believe Shift+F1 is more discoverable. (It also frees up F2 to use for "Rename"). So I would be quite happy if the shortcut Shift+F1 was hard coded into the pattern for tooltip dialog, which would make it even more discoverable. :smile: ]

[carmacleod]

Tooltip dialog seems like a good use case for the new aria-haspopup="dialog" property?
http://w3c.github.io/aria/aria/aria.html#aria-haspopup

[craigkovatch]

Has any work started on this? We are waiting on this before implementing our own interactive tooltip and the linked December deadline is coming up fast :)

[dicley]

any progress about the example from anyone, guys?

[craigkovatch]

I'm wondering if this has been abandoned, giving the new language on Tooltip https://www.w3.org/TR/wai-aria-practices-1.1/#tooltip

Tooltip widgets do not receive focus. A hover that contains focusable elements can be made using a non-modal dialog.

[carmacleod]

A hover that contains focusable elements can be made using a non-modal dialog.

IF the tooltip dialog pattern has indeed been abandoned in favor of a "hoverable non-modal dialog", then the keyboard handling of such things (i.e. summon with Shift+F1, close with Esc) needs to be added to the non-modal dialog pattern. Not to mention the possibility of allowing hover to open a dialog.

My personal preference would be to keep the tooltip dialog pattern, and allow tooltips to take focus under certain conditions (e.g. the user typed the "focus tooltip" key, or they hovered and then clicked, etc).

[0ddfell0w]

Is it fair to say this is the direction this is heading:

• If the hover does not include interactive content, use a tooltip (role tooltip) that will never receive focus.
• If the hover includes interactive content, use a tooltip dialog (role dialog, which opens when the described element is hovered or focused, and closes when it loses hover or focus).

If indeed the tooltip dialog should open on focus, is it appropriate to trap focus in the tooltip dialog? One concern is that this would force a keyboard user tabbing through the page to pause and Escape out of the dialog.

[zelliott]

Any update on the status of the tooltip dialog vs non-modal dialog patterns?