Arve Bersvendsen

Accesskeys needs replacing

If you dislike rants, you might as well stop reading now

This week, A list apart is running a story on accesskeys. As you may, or may not have noticed, this site is totally free from accesskeys. I’ll explain why.

Access keys interfere with normal browser operation

On Windows MSIE and Mozilla, access keys are activated by pressing alt+{accesskey}. Unfortunately, this is also the standard mechanism for opening any of the main menu items. For instance, alt+a brings up the Favorites menu in Internet Explorer. If you, for instance bind that key to bring up an about page, a user that wants to access that particular menu will have to first press the alt key and then release it, before finally pressing the a key again.

Reducing the vocabulary

Ideally, this could have been resolved by using only access keys that aren’t already bound to other keyboard functions. But how much should we reduce it?

If we iron out the keys that are occupied by default in English installations of either Mozilla or MSIE, we are left with the following access keys: c, d, i, j, k, l, m, n, o, p, r, s, w, x, y and z.

We could also factor in the different access keys used by translated versions of the browsers. They generally use different shortcuts to access any of the main menu items, for instance, the r key is bound to the Rediger (Edit) menu instead of e. Add another language, and the list gets even shorter.

I’m going to spare you the agony of different keymappings in localized browsers: Opera’s implementation of keyboard interaction and access keys make the available list short enough: i, m, n, o and w.

Opera has mapped large portions of the keyboard to different functionality, from navigating between links or other elements on a page, such as paragraphs and headers, to cycling between tabs. That these functions interfere with the use of access keys may be considered a bug, but nevertheless it’s something you have to take into account if you want to provide accesskey functionality.

Accessible to whom?

Accesskeys are supposed to be an accessibility feature. The problem is this: There is no default mechanism in any of the major browsers that describes which access keys are in use on a page, so authors often have to rely on CSS to provide visual clues to the access keys.

The keyword here is “visual”. One particular group of disabled users that would benefit greatly from access keys do not need visual clues. Yes, I’m talking about blind users. They cannot make use of underlined text, nor is CSS generated content that show the access key in question when they hover an element with the mouse.

Learn & relearn ad infinitum

The elegant solution to everything would of course be if web site authors just used a standard scheme for access keys, like suggested by Jukka M. Korpela?

The problem arises when an author does not follow these conventions: The user needs to relearn the access keys for each and every site he or she visits, or make more or less educated guesses as to which access keys are available.

Poor man’s <link rel=”“/>

Often, when authors use access keys, they simply use them as convenient shortcuts for various <link rel=" "> relationships, like rel="search", rel="home" or rel="about".

A proper browser implementation would provide keyboard access to the various <link /> relationships. Opera already provides keyboard access for some of these, like Ctrl+Shift+Left and Ctrl+Shift+Right for next & previous relationships, and Ctrl+Shift+F for Search.

Rounding up

Please understand, after reading this, that I am not an opponent of access keys as such, as we surely need to provide users with multiple mechanisms for navigation, but I feel we need a better way to define these mechanisms.

My initial thought is that we should find a standard set of access keys that are usually available on a site, like those used to bring focus to a particular form field. Example:

If a form contained a User Name field, one could perhaps define an access mechanism for this, instead of defining a key. <input type="text" access="username" />. Likewise, if a form contained a “password” field, one would have <input type="password" access="password" />.

This way, it would be up to the browser to provide a mechanism, be it voice input, mouse or joystick gestures or an accesskey to give this particular form field focus.

With an approach like this the author of a document would not need to consider which accesskeys might or might not work, it would simply be a function of the application.

From a users’ perspective, the benefit is that he or she no longer needs to learn the different access keys for a site, it is simply reduced to a question of learning the keyboard shortcuts the browser provides.