Why Aren’t Tooltips Triggered by The Keyboard?

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.

The first time I pondered the question was in 2004, and my response then was to write some JavaScript that would plug the hole. This is the script I came up with, and it certainly does the job. Were I to rewrite that today, I’d fork the event model between 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?

All imperatives aside, a JavaScript solution can never be as tightly integrated as a solution that’s generated by the OS itself; it can never really be more than a standby solution.

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?