Skip Navigation Home Search Contact

Using Accesskeys - Is it worth it?

The HTML4 feature known as ACCESSKEY is a navigational enhancement that allows you to jump to an active element (such as a form control or a link) on a page with a single keystroke.

The Accesskey attribute assigns an access key to an element. An access key is a single character from the document character set. Pressing an access key assigned to an element gives focus to the element. The action that occurs when an element receives focus depends on the element. For example, when a user activates a link defined by the A element, the user agent generally follows the link. When a user activates a radio button, the user agent changes the value of the radio button. When the user activates a text field, it allows input, etc.p>

The following elements support the accesskey attribute: A, AREA, BUTTON, INPUT, LABEL, and LEGEND, and TEXTAREA.

The invocation of access keys depends on the underlying system. For instance, on machines running MS Windows, one generally has to press the "alt" key in addition to the access key. On Apple systems, one generally has to press the "cmd" key in addition to the access key.

The rendering of access keys depends on the user agent.

Using HTML designated access keys:

Browsers that recognize HTML designated access keys:

Browsers that do not recognize HTML designated access keys

  1. Opera (PC versions up to 7.x, Mac versions up to 6.x)
  2. Netscape Navigator (versions 4.xx)
  3. * Under Mac OS 9, access keys are not supported by Internet Explorer 4, Internet Explorer 4.5, Mozilla, Netscape 4 and Opera 5.
  4. * Under Mac OS X 10, access keys are not supported by Mozilla and OmniWeb 4.

Now for the bad news...

In a non-scientific study conducted in the summer of 2002, we researched the availability of available Accesskeys which had not already been reserved by various other adaptive technologies, such as JAWS (see Jaws Keystrokes) and IBM's HomePageReader, a popular screen reading web browser, which has built in keystroke shortcuts for going into different modes.

HomePageReader makes no distinction between these keystrokes and will not allow you to use accesskeys. Besides, their mechanism actually seems to make more sense -- using links mode to cycle through a list of links seems much more useful and usable. (Interestingly, for accesskeys to work in HomePageReader, the user must first "click" the mouse within the display screen of the application... a curious requirement in a tool geared to the visually impaired...)

Disappointingly, our research discovered that all but 3 keys were previously "claimed" by one technology or the other:

At that point it was then pointed out (by Jukka "Yucca" Korpela - a well respected accessibility expert) that even these keys would be inaccessible to users not using a North American Standard (QWERTY) keyboard. So while it seems that Accesskeys is a great idea in principle, implementation brings with it the possibility that it either will not be available to all users, or that the keystroke combination encoded within the web page may conflict with a reserved keystroke combination in an adaptive technology or future user agent.

This potential problem was subsequently brought to the attention of the Canadian Common Look and Feel Access Working Group (who had previously suggested the use of Accesskeys M, 1 and 2), and after consideration the Access Working Group reversed it's recommendation and now suggest not to use Accesskeys on Government of Canada Web sites. (www.tbs-sct.gc.ca/cioscripts/help/specs_e.asp?who=/clf-nsi/)

Last Updated: October, 2006
(with thanks to Richard Walledge regarding updated Amaya information,
Sébastien Laoût and Marino Ceccotti for updated Konqueror information)

Unless otherwise noted, this work is licensed under a Creative Commons License Creative Commons License