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
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:
- Forms in HTML documents – 17.11.2 Access Keys
- ALA: Accesskeys: Unlocking Hidden Navigation
- WAI Accessibility Guidelines: Page Authoring: Links
- SitePoint: Using Accesskeys is Easy
accesskeyattribute in HTML forms and links
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
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
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.
Creative Solutions for
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.