Re: Article: Why Aren’t Tooltips Triggered by The Keyboard?

Some semi-random thoughts on tooltips:

I hope no one disagrees with the basic premises that one should have a keyboard mechanism for displaying the tool tip associated with the focus element (either automatically or on request), a way for the user to ensure that it's displayed long enough for them to read, a way to get rid of it if it's in their way, and a way to prevent them from being triggered automatically. (I'm not saying these should all be success criteria, nor that this is the complete list, just that ideally every product should give the user these capabilities.) It would also be nice for the user to be able to toggle the display of all tooltips at once, so one can get an overview of the page and more easily find the thing they're looking for.

I think it's generally less useful to be able to examine a list of all the tooltips associated with a window's content separated from the things they're associated with (e.g. a menu, or window with a list box), since in many cases the text won't be meaningful without its context. Same with the ability to navigate to elements based strictly on their tooltips, which might occasionally be useful, but I would not think it would be common.

Re below, note that pressing ESC to dismiss the tooltip only works if the tooltip itself takes the keyboard focus, as ESC may well have another meaning in the current context and we wouldn't want to prevent that from working just because--and as long as--a tooltip is displayed.

I notice Microsoft is inconsistent about tooltip timeouts: in Windows 7 they time out, but in Office 2003 they don't. Also, it appears the default duration for a Windows standard tooltip is 5 seconds, and the maximum is 32 seconds, which may not be enough given that they can have multiple lines of text, a title, and an icon.

Interestingly, tooltips are the one piece of text that neither mouse nor keyboard users can select and copy to the clipboard. One could imagine context menu items to display an item's tooltip and to copy its tooltip text to the clipboard, although I'm not sure it would prove useful very often.

If the capability to search based on text attributes as well as visible text (e.g. finding images whose alt text includes the search string) than this should ideally also work with tooltip text. This is easy when they're defined using the title attribute, but in some cases they're created dynamically when triggered. In cases where a page has a lot of dynamic tooltips, it would probably be prohibitively slow to generate all of them just so they can be searched.

-------- Original Message  --------
Subject: Re: Article: Why Aren’t Tooltips Triggered by The Keyboard?
From: Patrick H. Lauke <patrickl@opera.com>
To: User Agent Working Group <w3c-wai-ua@w3.org>
Date: 11/23/2010 2:20 PM
> On 23/11/2010 21:17, Jeanne Spellman wrote:
>> http://blogs.sitepoint.com/2010/11/23/why-arent-tooltips-triggered-by-the-keyboard/
>>
>>
>> IMO, the most interesting part was in the comments:
>>
>> <quote>
>> In short, the norm for tooltips is for their display to be decoupled
>> from keyboard focus, and this has clear usability benefits for users who
>> can use both the mouse and keyboard. Tying tooltip display to keyboard
>> focus would remove that benefit to the majority of users, who are used
>> to having it (and might switch to another browser because of such an
>> annoyance).
>>
>> The correct way to address the accessibility issue here, I would say,
>> would be to provide a method for keyboard users to peruse the tooltips
>> in a page independently of the current keyboard focus. Perhaps a new
>> pair of keyboard shortcuts for “Show Next/Previous tooltip”. Screen
>> reader users, similarly, should be free to browse the tooltips present
>> in a page without losing their place while filling out a form.
>>
>> I feel like there’s a solution in the offing, but it’s not as simple as
>> tying tooltips to keyboard focus. Perhaps Opera will be the first
>> browser to offer keyboard-driven tooltip navigation; it seems like it’s
>> the browser that tends to lead the way with these sorts of refinements
>> these days.
>> </quote>
>
> This seems like an over-engineered suggestion to me - a completely separate way to trigger tooltips separate from keyboard focus?
>
> The problems that Kevin mentions in his comment, just before your extract:
>
> <quote>Consider, that with mouse-triggered keyboard shortcuts, you are able to give a form field keyboard focus, view the tooltip, and then dismiss it (by moving your mouse away) so that it’s not in your way as you actually fill out the form field.</quote>
>
> This to me is merely an issue of positioning of the tooltip. If browsers displayed the tooltip even on keyboard focus, but kept it out of the way of the field (while additionally checking if it was indeed a keyboard navigation that set focus to the form field, rather than a click with the mouse, and allowing for something like ESC to dismiss the tooltip explicitly), this wouldn't be an issue.
>
> <quote>Likewise, you are able to view the tooltips of other nearby form fields without moving the keyboard focus from the current field (say, to determine how they differ from the field you are about to fill in).</quote>
>
> Keyboard users would be able to quickly TAB/SHIFT-TAB to adjacent fields, being able to do the same.
>
> IMO again, of course,
>
> P