Accessible Website Design :: Access Keys
Should we deploy website access keys?
Yes! The W3C recommends it! 25% [ 8 ]
No! They cause too many problems! 58% [ 18 ]
Don't know! 16% [ 5 ]
Total Votes : 31
I still use access keys but I may be about to stop using them because of the problems they cause.
My question (and poll) is - should we use access keys?
The W3C clearly says we should consider using them, and they should know more than all us put together!
I know they cause conflict, but shouldnt we (ie in the UK) just use UK Government Access Keys and force assistive software designers to leave out keys 1-10 from their shortcut keys? If we stick to a standard it will get (eventaully) recognised - will it not?
Or do you think the access keys system is just too flawed?
Last edited by Sandpetra on 03 Mar 2006 06:15 pm; edited 2 times in total
I feel that currently access keys are a little known and very confusing subject, those that use them have all sorts of different interpretations and therefore a web standard is called for. I am aware of the UK gov't standard, but how many webbies are
Personally, I resist using them as I feel mouse and keyboard navigation should be good enough for most if not all users and can't really see the validity of access keys.
Accessible to everyone
The idea is flawed: the author shouldn't provide (device specific) shortcuts; the author should work with semantics, then the UA should extract the semantics and provide a usable navigation mechanism to the user.
Most implementations are flawed: they clatch with shortcuts in the UA or the OS (even if you only use 0-9 as accesskeys; ALT+1 should insert a white smiling face "☺" on windows systems).
Users can't rely on accesskeys: only a fraction of web sites use them, and those that do are obviously more or less inconsistent.
Use the rel="" attribute instead. And good link text.
|A smiley face on windows? Well, we wouldnt want our access keys interfering with such an important shortcut (!) - forgive me, I'm an avid mac fan!|
|I've voted yes, but on the proviso that they are disabled by default and can be customised for the user's own preferences.|
I totally agree with this, hence one reason the accesskey class was created in the first place. the other being the clashing of keys set with other things, such as the browser itself!
|I'd still go for a grudging 'yes' if the UK Govt accesskeys standard is used, but I would say no for anything else.|
I wouldn't, as has been pointed out, the alt + 0 is somewhat of a problem.
At one time John Foliot over at Wats.ca was keeping a list of the different uses that acesskey 's' was used for, I am sure it got into double figures...
By alllowing the visitor to set their own access keys they are more likely to be able to rmeember them, and probably use the same set on different sites. People have a difficult enough job trying to remember all the keyboard navigation keys that one progam can have, let alone a myriad of different sets of accesskeys on a ton of different sites.
my mind is on a permanent tangent
|I know they cause conflict, but shouldnt we (ie in the UK) just use UK Government Access Keys and force assistive software designers to leave out keys 1-10 from their shortcut keys?|
When using accesskeys, you have a choice: either (1) use only a predefined set, such as these 0-9 keys defined by the UK gov't, or (2) define access keys for your own site (perhaps sharing some of them with the "standard set").
Ad (1): I really don't see the added value of 10 predefined access keys as compared to the use of <link rel="..."> elements. Moreover, some of the predefined links may not be useful on my site, whereas I'd like to have other access keys that aren't in Her Majesty's list.
Ad (2): Defining things on a per site basis is likely to confuse visitors, unless they can be told clearly and in a consistent manner what the access keys on a given site are. For the sake of consistency, this should not be left solely to the site author. Nor should you have to use an access key to see access keys details. The only sensible solution is for the browser to put that information somewhere, e.g. in a panel next to the page.
I'm not afraid of conflict between access keys and browser functionality. It's up to the browser builders to invent a good implementation.
Perhaps when browsers offer a good user interface for access keys (like listing the access keys available on a page in a panel next to the page), I may reconsider. But for now, I don't think it's worth the effort.
Also, the <link rel="" ... > elements provide an exhaustive range of destinations which UAs can easily implement into their interfaces. That is their intended purpose and what they are designed for. They can be a toggablable toolbar, a browser submenu, a sidebar or even be accessed directly by device-specific keyboard shortcuts.
However, some repetitive functions are not covered by <link> elements. For example, Preview and Submit on message forms. At Wikipedia they use S and P for these and, for the most part, that works very well. I've been using it in my Invision forum templates and it works well there, too.
The problem is resolving conflicts between access keys being used by the data and the same access keys already in use by the device. Convoluting the keyboard shortcut to use data access keys (Shift+Alt+Accesskey) is one solution. Toggling the device input mode (such as using Shift+Esc in Opera) is another solution. Having this toggle as a user preference which is saved between sessions is probably the least of a hack for UAs to implement.
It's unlikely that good UA implementation of access keys will ever become widespread due to them requiring the data to take control of the device. I think they can be useful in edge cases like Preview and Submit on messaging systems but that's about it.
All times are GMT