Why aren’t GUI tooltips triggered by the keyboard? Is there a solid reason, or is it just a collective blind spot?
One aspect I particularly enjoy about blogposting is reflecting back on how approaches and techniques have changed over time. How ideas that were revolutionary can go on to become commonplace, or how those that seemed progressive end up being forgotten and useless.
But in the case of how tooltips behave, there’s been no change in a decade—they were mouse-only then, and they still are today.
DOMFocusIn (a DOM 2 user-interface event that’s supported in most modern browsers and bubbles), and the proprietary
onactivate event for IE (which behaves like
onfocus, but also bubbles). The important distinction here is that the standard
onfocus event isn’t supposed to bubble, and doesn’t in most implementations (except in Firefox, primarily). But if we use events that are designed to bubble, we can implement the behavior with a single event-listener, rather than having to add a listener to every focusable element individually, as my original solution did.
I still implement that script on my site, often adding similar functionality to new applications I develop, both personal and client projects alike. Recently, for example, I’ve been working on updates to all five versions of CodeBurner—our reference tool for web-developers—and for some of those environments I’ve needed scripted solutions. In the Adobe AIR runtime, for instance, tooltips aren’t generated for HTML elements at all, by mouse or by keyboard; instead, I implemented a broader solution that responds to all such events.
Each time I implement a focus-driven solution, though, I wonder why I’m still having to. And to be honest, I also wonder whether I should. If interfaces typically lack focus-driven tooltips, is it right for an individual application to override that behavioral norm and implement them anyway?
Positioning is a problem, to give just one example, because document-generated elements can’t move outside the window. And even if they could, we’d still be limited to tooltips that come from document elements. We’re unable to provide them for the window buttons, or for anything outside the browser.
Opera is one browser that does offer keyboard-triggered tooltips in some fashion; for example, it shows link tooltips when they’re focused via spatial navigation. But even there, these tooltips are limited to the document it’s displaying. If they’re a good idea there, why aren’t they a good idea for the browser chrome itself?
So, in all the years that operating systems have had the sophistication to be able to generate tooltips, as well as the accessibility framework to cater for keyboard-only users, why have these two features never come together?
Why do tooltips remain mouse-only functionality?
If you want to read more from James, subscribe to our weekly tech geek newsletter, Tech Times.