Once upon a time, I believed that Accesskeys were the unequivocal solution if you wanted to provide a keyboard-based shortcut system within a website. The WCAG (Web Content Accessibility Guidelines) 1.0 guidelines specify:

"Keyboard access to active elements of a page is important for many users who cannot use a pointing device. User agents may include features that allow users to bind keyboard strokes to certain actions. HTML (HyperText Markup Language) 4.01 allows content developers to specify keyboard shortcuts in documents via the "accesskey" attribute."

Admittedly, this is not a commandment — however, it is certainly a reasonably strong recommendation! However, although the Accesskey attribute is the only HTML native means of providing a keyboard shortcut, I have recently become aware of several compelling reasons to avoid itNote 1.

John Foliot of WATS.ca has written numerous articles about these problems — so I’ll merely summarize here. The root of these concerns is that software, including standard browser software and screen reading software, is usually equipped with a set of standard keyboard shortcuts.

The problem should begin to become clear, now. How can a web developer use a technique which directly subverts the normal behavior of the user’s software and claim to be "accessible"? Consider this:

Alan, who is blind and using Internet Explorer 6, is visiting your website, in search of some piece of important information. Alan is highly adept with his software – the JAWS® screen reader for Windows. Alan realizes that this is not the right site for his information, and hits ALT+D – which is a standard JAWS method to return to the address bar – suddenly, he finds himself at your page on the Dalmatian. Since Alan can’t get to
the address bar using his usual method, he doesn’t know what to do! He has to shut down JAWS and start over.

If I was Alan, I’d be rather upset. I’ve wasted a fair amount of time! As much as I understand the desire of most website owners to keep people at their site – this seems a little extreme.

This example applies to Internet Explorer 6 and earlier. The experience with other browser software will be different; although not necessarily better. Internet Explorer 7, for example, uses the Alt+keypress combination to focus the cursor on the relevant link. This prevents the sudden and unexpected change in location, but does not solve the problem that the normal keyboard shortcut is no longer usable. You should never assume that any given user is using any given software. The example is a perfectly valid demonstration of what can go wrong with accesskeys. Keep in mind that this is not intended to imply that this problem applies to all devices: simply that it can potentially be a problem.

On early sites, I went out of my way to make certain that every major page had a unique accesskey – now, I realize that I may have inconvenienced the very people who were intended to benefit. Afterall, accesskey attributes are intended for the visually disabled, primarily – and these are the very people who are more likely to be regular users of keyboard shortcuts on their own software.

This entire subject came up as part of a discussion on the GAWDS discussion list. Thankfully, there are a large number of very talented developers participating on this list. Two of them, Gez Lemon of JuicyStudio and Rich Pedley teamed up to create a PHP (Hypertext PreProcessing) class that gives users the
ability to choose accesskeys for themselves.

This tool takes the need to choose access keys out of the hands of the web developer and puts it back in the hands of the user – where it belongs.

1. There are other alternatives, such as using JavaScript to program keyboard shortcuts. However, these "solutions" have the same problems as accesskeys, in addition to a dependance on client-side scripting to function. Return to Text