Access Keys - A Potential Solution?
There has been an almost continious debate within GAWDS on the role of access keys.
Grant Broome has argued strongly, in the past, that access keys could be an extremely important facility for some user groups. John Foliot, on the other hand, has focussed on the dangers of poorly-implemented accesskeys and concluded that they were probably best avoided.
The net result of these valid, yet contradictory, opinions was that is was impossible to develop consistent guidance for developers. The arguments against the use of accesskeys focussed on three significant issues:
- Keystroke conflicts:
- Poorly researched access key mapping can create conflicts with known
reserved key combinations - potentially creating a situation
where the accesskeys implemented on the site will actively
interfere with the normal operation of a given user agent. One general approch that minimises this danger is to restrict access key mapping to numbers but these are hardly intuitive. - Inconsistent access key mapping:
- Variations in key mapping from site to site - even when dealing with common site elements such as ‘Home’ or ‘Search’ - mean that potential users have to continually seek out, and attempt to memorise, many different access key lists.
- Real life usage:
- In theory, access key implentation could be beneficial to certain user groups such as those with mobility problems. However, finding someone who actively searches for access keys is harder than it sounds. When I canvassed a number of likely potential users, the comments I got back included:
“They vary from site to site, and I’d have to a) learn
whether a site has them, b) what they are on that site.”“The site should be designed in such a way as to not break
standard keyboard shortcuts.”
Of the three points listed above, keystroke conflicts and inconsistent mapping are technical issues that, theoretically could be resolved. But, was there any point trying to find a technical solution if the users themselves were disinterested in the concept? In fact, it proved so difficult to find regular access key users that John Foliot issued a challenge:
“Show me one user, who honestly and truthfully seeks out accesskeys in their day-to-day web surfing usage.”
Recently, Gez Lemon met that challenge following a number of positive responses to his Access Key Companion article and bookmarklet.
It seemed that, by developing a small javascript bookmarklet that would reveal access keys on any site and allow visitors to toggle them on, or off, at will, Gez had provided a solution for both the keystroke conflict and inconsistent key mapping issues. Now users could actually see available access keys ,on any site simply by activating the bookmarket. If the bookmarket finds any accesskeys, they are be revealed as a list of links with an extra option to disable them if the user encounters any conflicts.
The responses Gez received suggests that there is a potential audience for access keys providing they can be easily revealed and disabled at will.
However, the ideal solution would be to allow users to map their own accesskeys on a per site basis - preferably via a server-side script rather than a client-side solution which depends completely upon the availability of Javascript. Gez quickly proved that this was theoretically possible using PHP and cookies and the race is now on to develop a practical, server-side solution…
I hope that the script is developed to include a set of pre-defined access keys.
The danger is that the user will be too daunted at the prospect of defining their own, or that they will set keys that are already in use by the browser. An option of setting the keys to something relatively safe like the UK government standard would be a very good addition IMO.
I’m really glad to see this moving forward. It’s a genuine result for lots of mobility impaired keyboard users.
I appreciate that, especially for new users, being presented with a completely new set of choices could be overwhelming. However, I think there may be some issues with providing a suggested set of pre-defined keys within the context of a form.
For example, a site implements the script and identifies 10 anchors, or links, that are likely to benefit from accesskey implementation. They also provide a set of pre-defined keys for users who may be unsure of what keys to use - maybe 0-9. User A then visits the site. S/he is an experienced user who has developed a series of well-honed strategies for coping with site navigation and, as a result, only wishes to set 3 or 4 accesskeys.
If the form/script allows the pre-defined set to be enabled by default when the form is submitted, User A is going to have to manually clear at least 6 input boxes to avoid the mapping of keys that s/he doesn’t want. That scenario may present some users with whole new set of problems to deal with.
Reversing the situation slightly - the form doesn’t set the pre-defined accesskeys by default but only if users select a box labelled “I want to use these keys” or uses a checkbox next to each input where they only want to use a sub-set. Again, we’re going to be asking users to complete a form that may be more complex than it really needs to be. And these may be some of the very users who find form completion to be particularly difficult.
Do we really want to make users jump through hoops if we can avoid it?
Alternative suggestion: Don’t provide a set of pre-defined keys but provide examples of keys that could be used - perhaps using UK Government guidelines (numeric keys 0-9) or based upon Mark Pilgrim’s list of accesskeys.
Using this approach, we don’t interfere with a user’s potential choice, we keep the accesskey selection form as simple as possible and we, potentially, educate users.
Following this train of thought, what would be a really nice ‘extra’ would be for site developers to provide a vehicle for more experienced users to submit lists of accesskeys that they’d found to be particularly useful. This could, theoretically, build up into quite a valuable resource - accessekys based, not on some theoretical guideline, but on actual, real life, usage.