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

Greg,

We dealt with this issue in the GNOME desktop - having a way to 
show/hide tooltips.  See the Global Keyboard Shortcuts section of the 
GNOME Desktop Accessibility Guide, at 
http://library.gnome.org/users/gnome-access-guide/stable/keynav-3.html.en  
Ctrl+F1 will toggle the tooltip display on/off for the focused item (if 
it has a tooltip).


Peter

On 12/8/2010 10:47 PM, Greg Lowney wrote:
> 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
>
>

-- 
Oracle <http://www.oracle.com>
Peter Korn | Accessibility Principal
Phone: +1 650 5069522 <tel:+1%20650%205069522>
500 Oracle Parkway | Redwood City, CA 94065
Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
developing practices and products that help protect the environment