Accesskeys: In-Theory vs In-Practice

The HTML “accesskey” attribute allows web authors to specify hotkeys for links within a page. The idea behind accesskeys is that they’d allow for keyboard-navigability within a site (so far, so good).

One issue which cropped up early in the web-wide adoption of accesskeys is their discoverability — because accesskeys work behind the scenes, users generally wouldn’t be aware of their existence unless the author linked to a separate page which specifically outlined the accesskey assignments which he or she arranged.

Fortunately, that too resolved itself, in part through the UK’s Disability Discrimination Act which mandated accessibility for all UK-based websites. Along those lines, the UK Government provided a set of recommended accesskeys with the idea that users wouldn’t have to relearn the accesskey assignments for each site if all of them agreed to a common set of accesskeys.

As it turns out, that’s largely the extent of the good news about accesskeys. The downside to accesskeys is based on the means by which web browsers implemented them — and, more specifically, how browsers resolved conflicts between page-defined accesskeys and built-in browser-hotkeys. For instance, if a page author defined the “T” for a hypothetical link labeled “tangerines”, that would result in an accesskey of Alt-T or Ctrl-T (on PCs and Macs, respectively)…

What about the “Tools” menu, then, which would normally be activated with Alt-T? Well, current browsers allow accesskeys to prevail in those instances; all the same, overriding the built-in browser hotkeys may disorient users that are used to those hotkeys. Worse still, there’s more to worry about than just F/E/V/G/B/T/H (File, Edit, View, Go, Bookmarks, Tools, and Help). While those letters may correspond to the browsers’ menu items in the US-English versions of web browsers, localizations targeted to various countries across the world make use of entirely different menu items and corresponding hotkeys.

The end result is that just about every letter in the alphabet is already accounted for — assuming that you don’t want to override any of the user’s built-in browser functions. An informal study by WATS.ca (Web Accessibility Testing and Services) revealed that the only unused keys that were left for accesskeys were slash (“/”), backslash (“”) and right square-bracket (“]”). In theory, those keys could be used safely for accesskeys, but they leave a little to be desired in their mnemonic potential.

The end result? Accesskeys are nice, in theory; in practice, however, they’re not as useful as they might initially seem. Put another way, many see accesskeys as a good idea but one which ends up with slightly more disadvantages than advantages. On the other hand, since international browser usage is at the root of accesskeys’ less-than-usefulness, a site with a domestic-only audience may still be able to use accesskeys effectively. For example, an intranet for a US-bound company would be an ideal site on which to make use of accesskeys.