The Trouble With Accesskeys
When I first heard about the accesskey attribute in HTML I thought "Wow! What a great idea" and started to apply them willy-nilly to projects I was undertaking at work. Some time later, I started to read other articles that described problems with using accesskeys, problems that I would not discover by myself unless I were using a Screen Reader (something I'd do infrequently during testing cycles of sites at work) or some other assistive device. What's the problem? Well, in a nutshell, the key that you as an author choose to activate a link/form element/whatever could very well conflict with keys that are already assigned elsewhere. I then came to the conclusion that this great idea is flawed (as did many others) and stopped using them altogether.
The next iteration of XHTML should sort out issues like that, surely? Apparantly not. In The XHTML Role Access Module still flawed, John Foliot summarises how a few years of badgering the various XHTML 2 draft authors appears not to have achieved the desired result:
I continue to maintain that, as currently presented, one of the fundamental flaws of ACCESSKEY will be carried through to this new Element and attribute so long as the @key attribute remains. While I come to this discussion primarily as an Accessibility Advocate, I believe the issues will in fact impact upon all users to some extent.
It's a fairly long open letter but worth a read. Note -it's not just John and Derek who can badger/bother/nudge the people responsible for the XHTML 2 draft, remember. If you feel strongly about it, you too can have your say.
Related
On the previous incarnation of Accessify, accesskeys were hard-coded and, almost certainly, clashed with assistive devices as mentioned in the article referenced above. Strangely, no-one ever wrote in to complain that this was the case. Regardless of this, I decided to try and tackle the problem head on with an interim solution - and that was to create a system that allows the user to opt-in and set their own accesskeys. I'd be interested in feedback on this idea and suggestions for improvement.
4 Comments:
I also was first impressed by the idea of access keys but am finding them to be much more of a hinderance now.
The sites that use them are starting to annoy me. The problem being that the access keys clash with standard shortcut keys that I use for firefox.
For example, a number of sites use accesskey 's' for skip to content. This is what i use to turn sage (my newsreader) on and off. I frequently use alt+d to jump to the address bar, that has resulted in me jumping to a menu option on some access key sites.
I really think that access keys are a good idea, but something needs a rethink on this one or else access keys will become a hinderance to everyone?
Any thoughts?
Alex
(that being said i have them active in our site below.. im thinking about turning them off)
www.pixelapes.com
It actually should be pretty easy. The makers of browsers, screen readers and other assistive devices should simply have an accessKeys toggle. In short, something that over-rides the browsers default behavior in favor of the accessKeys defined by a site.
For example, holding down the "Shift" key, and then hitting Ctrl+[accessKey] would trigger that accessKey (if defined). Simply hitting Ctrl+[accessKey] would trigger the browser's/reader's/device's default behavior (say, "copy," if the accessKey was "c").
Alternately, there could be a hard toggle/option for using accessKeys over browser shortcuts. For example, hitting Ctrl+a+k would turn on accessKeys behaviour, and hitting it again would turn it off again.
Taking this a step farther, visual browsers would then be able to display the accessKeys visually, superimposing them over the element they're meant to activate, trigger, etc., when the accessKeys "mode" is turned on.
Opera has always implemented the kind of accesskey toggling Blair mentioned. You need to press Shift+ESC to enter accesskey mode. Then just press any key to trigger an accesskey.
This is not a problem with the specification, it is a problem with browsers. A browser shouldn't let a website remove browser functions from its user, should it...?
I also think that making Accesskeys
a) discoverable
b) customizable by the user
is very important. Here's a client-side solution which, I think, has some advantages.
Post a Comment
Links to this post:
Create a Link
<< Home