Keyboard Accessibility
Providing Keyboard Shortcuts Using accesskey

Article Contents

  1. Page 1: Introduction to Keyboard Accessibility
  2. Page 2: Providing Keyboard Shortcuts Using accesskey
    1. Overview
    2. Keyboard Shortcuts as a General Concept
    3. The accesskey Attribute, According to the Specification
    4. A Good Idea Implemented Poorly
      1. Browser implementation
      2. Screen reader implementation
      3. Browser conflicts
      4. Screen reader conflicts
      5. Language issues
      6. Numerals
      7. How do users know if accesskey shortcuts are available?
      8. Attempts to define standard accesskey shortcuts
    5. Should accesskey Shortcuts Be Used At All?
  3. Page 3: Altering the Default Tab Order Using tabindex

Overview

Keyboard shortcuts are a good idea for software design, and would be a great idea for web design too, if there were better ways of making keyboard shortcuts available to users. The accesskey attribute was invented to allow web developers to add keyboard shortcuts to Web content, but the specification was vague and incomplete. As a result, developers of browsers and assistive technologies implemented accesskey support inconsistently and ineffectively. web developers can still use accesskey to create keyboard shortcuts, but there are many considerations to take into account.

Keyboard Shortcuts as a General Concept

Keyboard shortcuts can be useful to all computer users because they often allow for faster interaction than allowed by mouse clicks. Power users of all abilities frequently use keyboard shortcuts. Among people with disabilities, people who are blind or who have motor disabilities also make frequent use of keyboard shortcuts.

Keyboard shortcuts are a standard accessibility feature of most operating systems. For example, in almost any Windows-based program, you can type Alt + F to access the File menu, Alt + E to access the Edit menu, Alt + V to access the View menu, and so on. Other common keyboard shortcuts include Ctrl + C (copy) and Ctrl + V (paste). Microsoft has standardized these keyboard shortcuts to make it easier to access menus and functions quickly without having to use a mouse. Similar keyboard shortcuts exist for Macintosh and Unix operating systems.

Part of the convention of standardized keyboard shortcuts in Windows is to underline the letter of the character that serves as the keyboard shortcut. The letter "F" in the word "File" is underlined as a cue to users that a keyboard shortcut is present and which key activates the shortcut.

The accesskey Attribute, According to the Specification

Starting with HTML 4.0, the accesskey attribute can be added to any of the following HTML elements:

  • a
  • area
  • button
  • input
  • label
  • legend
  • textarea

The attribute itself is simply added within the element, as in the examples below:

<a href="http://www.webaim.org/" accesskey="w">WebAIM.org</a>
<form action="submit.htm" method="post">
<label for="name">Name</label>
<input type="text" id="name" accesskey="n" />
<input type="submit" id="submitform" accesskey="s" value="Submit" />
</form>

The accesskey is a shortcut to the specified destination. In the examples above, the "W" accesskey would take the user to www.webaim.org. The "N" accesskey would take the user to the text input field, and the "S" accesskey would submit the form.

A Good Idea Implemented Poorly

Unfortunately, the recommendations are rather vague as to how best to implement keyboard shortcuts. Browser developers, assistive technology developers, and Web content developers were left to chart their own course. Despite good intentions, the result has been an almost complete failure of the idea to take hold in Web development practices.

Browser implementation

Browser implementation varies widely between brands and operating systems. Still, the basic idea behind accesskey shortcuts is fairly consistent, even though implementation varies. Users can get accustomed to the way their favorite browser handles accesskey shortcuts, but may have to learn new methods if they switch to another browser.

Keystroke combinations

Different browsers use different keystrokes to activate accesskey shortcuts, as shown below:

  • Alt + [the accesskey]
    • Internet Explorer for Windows
    • Firefox for Windows
    • Mozilla for Windows
    • Netscape 6+ for Windows
  • Shift + Esc + [the accesskey]
    • Opera for Windows or Mac
  • Ctrl + [the accesskey]
    • Internet Explorer 5.2 for Mac
    • Safari 1.2 (Mac only)
    • Firefox for Mac
    • Mozilla for Mac
    • Netscape 6+ for Mac
  • Not supported
    • Camino (Mac only)
    • Older versions of browsers

Duplicate accesskey values

Most browsers do not support duplicate accesskey values. For example, a page cannot have two shortcuts with accesskey="1". Most browsers will ignore one of the shortcuts. Some browsers ignore the first instance, and other browsers ignore the second instance. The only browser which "supports" duplicate accesskey values is Internet Explorer for Windows, although this is only because Internet Explorer handles accesskey differently than other browsers (and some would say improperly), as explained below.

Image map hot spots (the <area> element)

As with the <a> element, all browsers follow the link except for Internet Explorer for Windows, which just moves the focus to the link.

Form elements

The <input> element. The focus goes to the <input> element. In the case of radio buttons and checkboxes, the browser not only moves the focus to them, but selects them. In the case of submit buttons, the form is also submitted, without having to press Enter.

The <textarea> element. The focus goes to the <textarea> element.

The <button> element. The focus goes to the <button> element and the browser submits the form.

The <label> element. The focus moves to the form element indicated by the label. For example, if the accesskey is in the label for an <input> tag, the focus ends up on the <input> element, not the <label> element.

The <legend> element. The focus moves to the first form element, such as an <input> or <textarea> element.

Screen reader implementation

Because screen readers depend upon browsers for much of their functionality, screen reader implementation of accesskey is largely dependent upon the browser being used. Most screen readers work with Internet Explorer, and so behave in the same way as Internet Explorer (complete with the quirky implementation of accesskey for <a> and <area>).

JAWS notifies users of accesskey shortcuts. For example if the accesskey value is 1, JAWS says "alt plus 1."

Window Eyes does not notify the user of any accesskey shortcuts.

Browser conflicts

One of the problems with the whole idea of accesskey is that there are bound to be conflicts between the keyboard shortcuts of user agents (browsers) and Web content. For example, as mentioned earlier, Alt + F on a standard Windows program will activate the File menu. What happens when a Web developer wants to use the same keyboard combination to access a part of the Web page? How this type of conflict is managed also depends upon the browser.

In the case of Internet Explorer for Windows, Firefox, and most other Windows-based browsers with the exception of Opera (discussed below), the accesskey in the Web page takes precedence over the keyboard shortcut of the user agent. This has the potential to cause confusion and frustration in users. What if the user wants to access the File menu, but is unable to because of an accesskey on the Web page which uses the F key? As it turns out, there is still a way to access the File menu in Internet Explorer, even if an accesskey is set to use the F key. The solution is to press the Alt key, release it, then press F. Not many users are aware that they can do this however.

Web developers cannot assume that users will know how to use accesskey shortcuts or to know the nuances of Internet Explorer menu keyboard shortcut activation techniques. To make matters even more interesting, the Alt+D accesskey completely over-writes the Alt+D keyboard combination in Internet Explorer to move the focus to the address bar. If accesskey="d" exists in the content, the user must find some other way of accessing the address bar. Not even the technique of typing Alt and then D separately will work.

The developers of the Opera browser were able to circumvent the problem of conflicting keyboard shortcuts by implementing a different keystroke combination: Shift + Esc + [the accesskey]. There are no keyboard shortcut conflicts when using Opera. The drawback of this implementation is that an extra key is required for every keyboard shortcut. It becomes somewhat less convenient in that sense, but at least users do not need to worry about two different keyboard shortcuts using the same keystrokes.

Screen reader conflicts

One of the biggest concerns with accesskey shortcuts is the possibility of the accesskey overriding the keyboard shortcuts of screen readers. This could potentially be a huge problem because screen reader users depend upon the keyboard shortcuts of their screen readers. If a screen reader keyboard shortcut is disabled by an accesskey shortcut, the user may not be able to perform important screen reader functions.

Luckily, this is more of an imagined problem than a real problem. In none of the cases do accesskey shortcuts override screen reader shortcuts. In all cases, the screen reader shortcuts take precedence, meaning that the accesskey shortcuts are effectively disabled. The accessibility benefit of accesskey shortcuts is lost, but screen reader functionality is left intact.

JAWS is victim to all of the Internet Explorer accesskey shortcomings, but adds none of its own, at least in "desktop" settings mode. In the less-commonly-used optional "classic laptop" settings mode, however there is a conflict with an overwhelming majority of accesskey combinations. Luckily, the keyboard shortcuts of the screen reader take precedence. In a "worst case scenario," the accesskey shortcuts on the page may not all work, but the screen reader continues to work perfectly. This is not such a bad consequence. It would have been worse if it were the other way around.

Window Eyes allows all accesskey combinations except numerical combinations. The Alt + [any numeral] combination is reserved for user-defined functionality. If an accesskey shortcut is defined by a numeral (0-9), it will not work in Window Eyes.

Language issues

Are there any keystrokes that do not conflict with any browsers, assistive technologies, or operating systems? In short, no. All of the keystrokes are either already known to conflict with existing software, or may in the future conflict with software not yet developed. This is especially true when foreign languages are taken into account. The File menus in browsers are not named "File" in languages other than English. The software may say "Archivo" (Spanish), "Dossier" (French), "Lima" (Italian and Portuguese), "Akte" (German), or some other word in a different language, all of which may use different keyboard shortcuts.

Numerals

Because of the fact that every letter is presumed taken by some language in the world, some accessibility experts have advocated for the use of numerals, rather than letters, in order to minimize the overall impact of keyboard shortcut conflicts. It is true that there are fewer conflicts for numerals than for the letters, but Window Eyes has numerical conflicts, as has been discussed. This does not necessarily mean that numerical values are off-limits. They will indeed work for most users, just not for the ones using Window Eyes. Since this screen reader continues to work just fine regardless of accesskey conflicts, the "dangers" are limited for users of this screen reader—but so are the benefits.

How do users know if accesskey shortcuts are available?

One of the biggest problems with accesskey shortcuts is that users are not aware that they even exist, and there is no standard way of notifying them. Unlike the Windows environment, which underlines the letter of the keyboard shortcut in menus, there is no convention or "rule-of-thumb" for alerting users to the presence of an accesskey shortcut. Developers may choose to mimic the conventions of the Windows environment, or they may invent their own. All of these efforts, though well intentioned, fall short of the ideal. The ideal would be to have the user agents identify accesskey shortcuts for users. It should not be the responsibility of the developers at all. Nevertheless, since this ideal scenario does not yet exist, if developers choose to use accesskey shortcuts, they must somehow notify users that the accesskey shortcuts are available. Some methods of accomplishing this are:

  1. Underlining the letter within a word that activates the accesskey, for example: Next Page.
    • Advantages: Easy to implement. Some users will recognize this convention.
    • Disadvantages: Not all users will recognize this convention; all users know which keystroke combination to use (is it Alt, Ctrl, Shift, etc.?).
  2. Putting the accesskey in parentheses, for example: Next Page (Access key: N)
    • Advantages: Easy to implement. All users will be able to read the text.
    • Disadvantages: This changes the layout and look and feel of the Web content. Not all users will recognize this convention.; not all users know which keystroke combination to use.
  3. Put the exact keystroke combination in parentheses, depending on which browser is being used, for example: Next Page (Alt + N)
    • Advantages: This tells the user exactly what keystroke combination to use.
    • Disadvantages: Requires browser detection scripts, either with JavaScript or server-side scripts; changes the layout and look and feel of the Web content.
  4. Create a list of accesskey shortcuts on a separate page and linking to them from all pages on the site that use the accesskey shortcuts. For example, the link could say "List of keyboard shortcuts" which would take the user to a page that list them all.
    • Advantages: This puts all of the keyboard shortcuts in one place for easy reference
    • Disadvantages: Users must go to a separate page in order to learn the keyboard shortcuts; requires the addition of an extra link on every page; users still may not know which keystroke combination to use (Alt, Shift, etc.) unless it is explained in the external file, in which case the file may be long and awkward.
  5. Use more sophisticated CSS and/or browser detection approaches that expose the accesskey shortcuts when the elements receive focus or when the mouse hovers over them.
    • Advantages: Does not interfere with visual layout; if both CSS and browser detection are used, then users can be notified of the exact keystroke combination necessary.
    • Disadvantages: Requires working knowledge of advanced CSS and/or browser detection scripts.
  6. Use some combination of the above approaches.

Attempts to standardize accesskey shortcuts

Both the United Kingdom (UK) and Canadian governments created a standardized set of accesskey shortcuts. The Canadian government eventually abandoned theirs, though (see the current Canadian government recommendation - external link), due to the many implementation issues already discussed. The UK continues to support its original list of standard shortcuts, which are as follows:

  • S - Skip navigation
  • 1 - Home page
  • 2 - What's new
  • 3 - Site map
  • 4 - Search
  • 5 - Frequently Asked Questions (FAQ)
  • 6 - Help
  • 7 - Complaints procedure
  • 8 - Terms and conditions
  • 9 - Feedback form
  • 0 - Access key details

Nearly all of the UK government Web sites have implemented these shortcuts. Some sites in Australia and the European Union have implemented these same shortcuts. The UK list is easily the most widely adopted standardized list of accesskey shortcuts, but that's still not saying much. The overwhelming majority of sites on the Web do not use accesskey shortcuts, and among those that do, there is still too much variation to be able to say that any sort of real standard exists.

Should accesskey Shortcuts Be Used At All?

The answer to the question of whether accesskey shortcuts should be used at all is not always an easy one. Due to the numerous problems in implementation, many developers choose to avoid them entirely—even developers who are staunch accessibility advocates. Even so, if they are implemented carefully, accesskey shortcuts can be beneficial to some users. Perhaps in the future it will be easier to implement accesskey shortcuts effectively. If that day comes, accesskey shortcuts will almost certainly be recommended by nearly all accessibility advocates. Until that day, it is really a matter of personal preference, with the realization that some users will benefit and some will not. Even if some people do not benefit from accesskey shortcuts—and as long as accessibility is not compromised for these people—perhaps it is best to provide accesskey shortcuts where appropriate, rather than deprive everyone of their potentially useful functionality.

WebAIM is an initiative of:
Center for Persons with Disabilities (CPD) Utah State University