Why Aren’t Tooltips Triggered by The Keyboard?

By James Edwards

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?

note:Want more?

If you want to read more from James, subscribe to our weekly tech geek newsletter, Tech Times.

  • That’s a really great question, James! I think the reason they don’t is because doing so usably would be a non-trivial problem to solve.

    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. 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).

    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.

  • That is a very good question — though it’s another of those lesser used accessibility things few browsers apart from Opera even take the time to consider.

    Take what happens with accesskey anchors that have title tags on them in Opera when you hit shift-esc. If every browser had that more coders might actually take the time to use accesskeys in the first place and it certainly is useful to pull up on mini/mobile with the handful of websites that support it.

    Though for me that’s the only justification for putting a title attribute on an anchor in the first place, since if you need ‘title’ on an anchor, you probably have the wrong content inside the anchor! See why I think most turdpress templates are garbage using IDENTICAL text in TITLE as they do inside the anchor — talk about pointless bloat.

  • Kevin, your comment seems like an over-engineered suggestion to me

    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.

    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.

    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).

    Keyboard users would be able to quickly TAB/SHIFT-TAB to adjacent fields, being able to do the same.

  • JoeFlash

    If you recall the earliest implementations of Tool Tips was not a small floating content box displayed next to the cursor. The Status Bar was the earliest tool tip implementation and this still a fairly common practice of most computer applications, even before they were used for web content. The was practice was becoming common until many web sites and advertisers began to abuse the use of the status bar causing most browsers to disable the access in favor of displaying the referenced web address of links and such.

    The practice of using a static status bar could now be reintroduced since browsers are better able to support static positioned web content in the browser window. Now a site can enable its own static status bar and display useful and descriptive information to the user in a consistent and accessible manner.

  • @JoeFlash: having the information so far away from the focussed/moused thing sucks for users with limited screen view (like with a screen magnifier). I CAN see my whole screen and find it annoying when I have to go to the status bar to figure out that the heck I’m hovering over (when links are unclear for example). That and we have to explicitly turn that on in Safari… meh.

    …In general I make titles appear on :focus using CSS, but this doesn’t work for all situations and of course misses IE6 and 7 most of the time. The trick is especially nice when the “designer” has insisted on obtuse icons that nobody can figure out what they do.

    • The title on focus/hover brings up another reason I like Opera…

      When an anchor has a title it shows you BOTH the title and the address the anchor resolves to on hover — unlike every other browser out there that lets you used title for link obfuscation.

      I just don’t get why they have a different set of code for showing :focus than they do for :hover — one of those places where it should use the same code and for some reason they didn’t.

Get the latest in Front-end, once a week, for free.