The accesskey attribute has been part of the HTML specification for over ten years and its purpose is to give keyboard users a shortcut to access a specific area of the page or to jump to a different page. In HTML5 the accesskey may be used on any element, but do web developers still need to use it?
The majority of users will never know that you’ve assigned accesskeys. Simply adding the attribute renders nothing visible to the front-end. However, JAWS will announce an item with an accesskey by saying “alt plus [whatever accesskey you specified]”, but unless you have specifically scripted a clever solution the general user won’t see that you’ve made the effort.
Here are a few ways of making the user aware of accesskeys:
- Webaim – Providing Keyboard Shortcuts Using accesskey (anchor to their ideas on how to make accesskeys visible)
- Firefox hack to display “accesskey” keyboard shortcuts
- Accesskeys: Unlocking Hidden Navigation
- User-Defined Access Keys
How have accesskeys made it to HTML5?
Although the HTML5 spec includes a number of new items, it’s creators have had to ensure that older elements and attributes in general use will continue to function in future implementations of browsers (currently only the longdesc attribute has been dropped completely). Enough developers have implemented the accesskey for it to be included in the new spec.
The public-html mailing list discussion on the accesskey attribute showed that the biggest motivation for including accesskey in HTML5 is to ensure backwards compatibility of mobile content (Japan came up often) rather than aiding accessibility on the desktop.
Mobile web development
We’re talking WAP and WML, but in early WAP standards the user interface of accesskeys was not specified exactly enough and so was implemented differently from phone to phone:
Thinking back to the good old days of WML (yes, there were some good things about WML) the accesskey attribute was pretty universally supported, and as a developer you only had to worry about assigning keys 0-9. Sure, there were some other things to worry about, like if you had to number the list yourself, or if the browser would apply the numbers automatically on your behalf.
These, perhaps outdated, mobile development technologies are less thought of now that we have mobile phones with full desktop version of browsers. For the foreseeable future there will be parts of the world using older mobile technology so accesskeys will still be visible to certain groups.
An answer to the question?
There are conflicting implementations and recommendations when it comes to implementing accesskeys. Personally, I think developers should continue to add accesskeys, with caution, to new websites but understand that a small minority might encounter some problems:
Window-Eyes will not announce numeric accesskeysUpdate from Andrew Downie in comments: In IE8, Window-Eyes 7.2 announces accesskeys, including those using numerals. It doesn’t, however, announce any in Firefox 3.6.
- JAWS will not invoke any accesskey that conflicts with it’s own functions
- WAP generally renders accesskeys visibly and due to device constraints numeric accesskeys are preferred
- Keyboard shortcuts for IE on Windows will be overridden by a conflicting accesskey, but the IE shortcut can still be accessed by pressing and releasing the Alt key before pressing the shortcut
- http://mobiforge.com: Blackberry ignores the attribute (it did a year ago), Windows Mobile actually supports it by defaulting the keypad to numeric mode.
If you do use accesskeys, I suggest following this attempt at a standard set of accesskeys as used by the UK government – it is almost totally numeric and the list has been widely cited in articles on the accesskey.
A combination of skip links, accesskeys and a well thought out document structure should be your goal.