Providing Keyboard Shortcuts Using
- Page 1: Introduction to Keyboard Accessibility
- Current page: Page 2: Providing Keyboard Shortcuts Using accesskey
- Keyboard Shortcuts as a General Concept
accesskeyAttribute, According to the Specification
- A Good Idea Implemented Poorly
accesskeyShortcuts Be Used At All?
- Page 3: Altering the Default Tab Order Using tabindex
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
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
support inconsistently and ineffectively. web developers can still use
to create keyboard shortcuts, but there are many considerations to take
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 menu, Alt + E to access the menu, Alt + V to access the 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.
accesskey Attribute, According
to the Specification
Starting with HTML 4.0, the
can be added to any of the following HTML elements:
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">
<input type="text" id="name" accesskey="n" />
<input type="submit" id="submitform" accesskey="s" value="Submit" />
accesskey is a shortcut to the specified
destination. In the examples above, the "W"
take the user to www.webaim.org. The "N"
take the user to the text
input field, and the
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 varies widely between brands and operating systems.
Still, the basic idea behind
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.
Different browsers use different keystrokes to activate
as shown below:
- Alt + [the accesskey]
- Internet Explorer for Windows
- Shift + Alt + [the accesskey]
- Firefox for Windows
- Shift + Esc +
- 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
Most browsers do not support duplicate
For example, a page cannot have two shortcuts with
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
is Internet Explorer for Windows,
although this is only because Internet
accesskey differently than
other browsers (and some would say improperly), as explained below.
Image map hot spots (the
As with the
<a> element, all browsers
follow the link except for Internet
Explorer for Windows, which just
moves the focus to the link.
<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.
<textarea> element. The focus goes to the
<button> element. The focus goes to
<button> element and the browser submits the form.
<label> element. The
focus moves to the form element indicated by the label. For example, if the
in the label for an
<input> tag, the focus
ends up on the
<input> element, not the
<legend> element. The focus moves to the first form element, such as an
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
and so behave in the same way as Internet Explorer (complete
with the quirky implementation of
JAWS notifies users of
For example if the
accesskey value is
1, JAWS says "alt
Window Eyes does not notify the user of any
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 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
In the case of Internet Explorer for Windows,
Firefox, and most other Windows-based
browsers with the exception of Opera (discussed
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 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 menu
Internet Explorer, even if an
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
over-writes the Alt+D keyboard
combination in Internet Explorer to move the focus to the address
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
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
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
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
override screen reader shortcuts. In all cases, the screen reader
shortcuts take precedence, meaning that the
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
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
Luckily, the keyboard shortcuts of the screen reader take precedence.
In a "worst case scenario," the
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
except numerical combinations. The Alt +
[any numeral] combination is reserved for user-defined
functionality. If an
is defined by a numeral (0-9), it will not work in Window
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. Themenus in browsers are not named "File" in languages other than English. The software may say " " (Spanish), " " (French), " " (Italian), " " (Portuguese), " " (German), or some other word in a different language, all of which may use different keyboard shortcuts.
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
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
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
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
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
accesskey shortcuts, they must somehow notify users that the
are available. Some methods of accomplishing this are:
- 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.?).
- Putting the
accesskeyin 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.
- 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.
- Create a list of
accesskeyshortcuts on a separate page and linking to them from all pages on the site that use the
accesskeyshortcuts. 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.
- Use more sophisticated CSS and/or browser detection approaches that expose
accesskeyshortcuts 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.
- Use some combination of the above approaches.
Attempts to standardize
Both the United Kingdom (UK) and Canadian governments created a standardized
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
- 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.
Be Used At All?
The answer to the question of whether
should be used at all is not always an easy one. Due to the numerous
problems in implementation, many developers choose to avoid them
developers who are staunch accessibility advocates. Even so, if they
are implemented carefully,
can be beneficial to some users. Perhaps in the future it will be
easier to implement
accesskey shortcuts effectively. If that day comes,
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
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
- The W3C
accesskeyspecification - external link
- Articles on WATS.ca - external link:
- Article on A List Apart:
Accesskeys: Unlocking Hidden Navigation - external link
- Microsoft information on
accesskeyfor Internet Explorer - external link
accesskeyguidelines - external link
- Canadian government
accesskeyrecommendation - external link
- Article by Jukka Korpela: Using
accesskeyattribute in HTML forms and links - external link