Consistent Accesskey Functionality
Accesskeys are an accepted piece of accessible design practices, yet there is little consistency in how they map to common functionality.
I am currently conducting research for a project, and one of the more interesting and less common items I have delved into is the use and benefits of accesskeys in HTML.
Right now there is a huge conversation in the blogodome about accessibility. Although I wasn’t there, it seems the @media conference stirred quite a bit of yummy chunks from the bottom of the web standards pot, and everyone from Mike Davidson to 456 Berea Street has touched on the subject. This discussion has been fascinating to listen to. (Much more interesting than farking Ajax, anyway.)
But in the world of accessibility, accesskeys seem to be taken for granted. The topic comes up every now and then, but at this point it’s a large assumption that of course we’ll put in accesskeys—that’s just good wholesome accessibility practice, silly. Many standards-conscious designers are even kind enough to visually label what accesskeys are mapped to which links, or at least provide a list in the accessibility statement.
My initial goal was to find a recommended list of what accesskeys should map to what functionality. A best practices article, in other words. While I found many accessibility statements where I can pull averages, a bit from Dive Into Accessibility and some stuff from the W3C, nowhere could I find a central list of recommended keyboard shortcuts.
Some sites use all numbers, others use numbers and certain letters that map to the navigation. Some just use navigation shortcuts.
Diving a bit deeper into Google, I found the article “Accesskeys and Reserved Keystroke Combinations” on wats.ca, which is a nice chart of keyboard shortcuts used by common browsers and the two main players in assistive technology, IBM and JAWS. This relates to the debate on whether to even use accesskeys since many mirror common keyboard commands in the software itself. For instance, hitting Alt+H in Internet Explorer and most other programs will activate the Help menu, but if a site decides to use “H” as an accesskey for “Home,” then that could significantly interfere with software usability.
Taking this into consideration, and taking in the average of other sites, we can deduce some best practices in what accesskeys to use for what functionality.
- Accesskey 1—Home. Using the example above, we need to avoid “H” altogether and this is the next logical choice.
- Accesskey 2—Jump to content / skip navigation. This was recommended by Mark Pilgrim in Dive Into Accessibility, and I’ve seen it widely adopted on other sites. There is some discrepancy among various sites, but “2” seems to be used most.
- Accesskey 4—Search. Either a dedicated search page or the button that activates the search button.
- Accesskey 9—Contact. Every site should have a dedicated contact page. Accesskey “C” could also work, since it is not widely used by other software, but “9” is recommended and put into practice by most sites.
You’ll notice they’re not letters. Using the handy chart mentioned above, it’s easy to see that almost all letters are taken by any one of all of the software titles. While some letters are fairly unused (“R,” for example), a good chunk have been claimed by software functionality. Of these, we can form a blacklist of accesskeys to avoid: D, E, F, H, T, V and W.
Although there are a few sites that have navigation-specific shortcuts (such as the first letter of each section), most are content in providing a simple navigation framework comprised of the numbers above. The ultimate goal would be to provide a dedicated list of recommended keyboard shortcuts, not unlike what the UK government offers in UK Government Access Key Standards.
Moving forward, it would be best to have a consistent accesskey scheme. This would allow for software manufacturers to create their keyboard commands around a published list of keys as well as not force users to learn new key commands for every website they visit.