Giving Control with Accesskeys

As a site developer, you truly have the most control over the presentation and usage of any project you’re working on. That is, unless your client feels equally. It is up to you how the navigation will work, where design elements are placed, and how the site content is conveyed to the user. With that comes a responsibility to follow good practice and keep usability and accessibility in mind.

Navigational structure is very important when developing. If content isn’t easily usable and accessible, the chance of certain content not being found increases. We as developers try to avoid this at all cost and make sure that if a user has a piece of information they’re looking for, it is very easy to find and finding it is quickly done. One way to provide quick navigational use is providing accesskeys.

What are accesskeys?

To put it simply, accesskeys are keyboard shortcuts for the Web. They allow a user to navigate a site using the keyboard by pressing ALT on PC or CTRL on Macintosh in combination with an assigned letter that relates to a navigational element. They can be implemented using the following:

<a href="/" accesskey="h">Home</a>

Many articles have been written on the general idea of this topic, so I’d like to provide some prerequisite reading:

Each article is a great overview as to what accesskeys are and what they do, so what I would like to talk about is: why accesskeys still aren’t popular. I think Dave Shea put it really well when he wrote I Do Not Use Accesskeys, there is no standard for accesskey use and when implemented, can be very confusing. Browsers currently do not provide an override for accesskeys, so as a developer, you need to ensure that the accesskeys you implement are not already being used by a browser one of your visitors may be using. That can be a tiresome process and often results in an obscure accesskey that has lost all meaningful identity and seems to be included as a last ditch accessibility effort. Currently, that is the number one reason I do not implement accesskeys in practice.

Why not Standardize accesskey Usage?

There have been some movements to provide a standard for accesskey use, but they haven’t really been adopted. Personally, I think that coming up with a standard for accesskey definition and use would be great, but I also think it would be terribly difficult. Each site navigation is very different in itself. Although there are often common elements in the majority of site navigation, the question arises about what to do with those items that aren’t standardized?

The truth of the matter is, a markup language for a very diverse collection of documents has been standardized (read: W3C), so why not accesskeys? Is it that people generally aren’t even interested in their use?

A Lack of accesskey Interest

Personally I’m using accesskeys all the time. Hardly ever while browsing the Web, but I’m always using keyboard shortcuts while writing code, styles, articles, switching between open windows (ALT+TAB for instance), and using the keyboard for many other activities that can also be done on a mouse. How many developers can say they’re still using File > Save when saving a file instead of CTRL+s? While it is such a small task, it is second nature for me now. Why is there such a success with keyboard shortcuts on the desktop, and such a failure with accesskeys on the Web? It’s because keyboard shortcuts in applications are more or less standardized. You know that CTRL+s will save, CTRL+o will open, and CTRL+p will print.

What About Web Applications?

With Web applications really taking off, I feel that accesskeys would become more effective to use and allow for tasks to be more easily completed. For instance, I am using a custom CMS each and every day at work, and having accesskeys would help me get my job done that much quicker. The major drawback is again, that there is no override for browser keyboard shortcuts, so implementation would be difficult and have a learning curve.

Dave Shea also touched on this issue and said that he’s still off accesskeys and really examines accesskey usage.

Creative Solutions for accesskey

Roger Johansson has put together a collection of creative solutions which would enable the user to define their own accesskeys. This is an interesting direction to head in, and there are pros and cons associated with the idea. I haven’t tried to implement any of the solutions so I don’t have a personal opinion on the techniques, but the idea is intriguing.

The W3C practices providing a page dedicated to accesskey usage on their Validator which allows for some clarity to their users. A drawback to their implementation, however, is that numbers are used to represent the accesskey. Numbers are not meaningful identifiers and are not intuitive to use, but in a situation where there is no accesskey override, their use is an effective solution.

So what Happens Now?

Personally, I’m thinking that accesskeys have pretty much found their place and will remain there. I don’t think they will be adopted very much due to the major drawback of having to use obscure key definitions. Until a browser override is provided by every browser, I will not be implementing accesskeys unless the situation can absolutely be assisted by their inclusion.