Access Keys
Access Keys have once again found its way onto the GAWDS mailing list, as it does at least once a year , and surprisingly John Foliot has not thrown his hat into the ring. John, co-founder of WATS.ca, is one of the most vocal proponents against implementing accesskeys in their current state of support in modern browsers and I do agree with him, but I do see the value in their use in a limited manner. John is also very against the W3C’s XHTML 2.0 specification’s (a work in progress) implementation of the Key attribute which, when used together with Access element, will basically implement the Accesskey again as it is now – a designer specified key combination. This is a problem that really needs to be addressed. Email the W3C (www-html@w3.org) and leave your thoughts about this and let them know that the Key attribute is not acceptable and needs to be removed from the specification. For the real specifics of the issue see his article: ACCESS + KEY still = ACCESSKEY – The XHTML Role Access Module still flawed.
The XHTML 2.0 specificationprovides for the @role attribute which will result in a better implementation allowing user control over the keys that are assigned to roles (and not the site author) allowing key combinations that are intuitive to the user (because they will be able to be user defined). One of the current problems with access keys and the Access+Key features of the XHTML 2.0 specification is that they will most likely be different on each and every site that implements them because they will be defined by the site’s designers. There will be some that will be the same, but I think that they might be the exception and not the rule. For these technologies to be really usable for web users at large they need to be standardized (as some Roles will be) and user defined. Anything other than that will generate usability and accessibility issues.
Working with Access Keys
The discussion brought up some interesting ways to allow the Accesskeys to be user defined. A few client side Javascript based solutions were offered (Accessify.com and
a Juicy Studio Experiment), but the problem, of course, is that these will not work if javacript is disabled or not available on the accessing user agent. The preferred solution, I believe,
is a server side solution, that way its functionality is not dependent on client side technology.
Related Links
Following are a list of links related to this topic so that you can make the decision to use or not to use Access Keys yourself! These may be a little biased but take it as you will. =)
WATS.Ca Links
- ACCESS + KEY still = ACCESSKEY – The XHTML Role Access Module still flawed
- Accesskeys and Reserved Keystroke Combinations
- Using Accesskeys – Is it worth it?
- More reasons why we don’t use accesskeys
- Link Relationships as an Alternative to Accesskeys
- The Future of Accesskeys
Other Access Key Links
- Day
15: Defining keyboard shortcuts: Dive Into Accessibility - Access
Key Companion:: Juicy Studio - Usage
of the Link Element::FreeXenon
World Wide Web Consortium’s Related Specifications
Did you enjoy this post? Why not leave a comment below and continue the conversation, or subscribe to my feed and get articles like this delivered automatically each day to your feed reader.
No comments yet.
Leave a comment
Line and paragraph breaks automatic, e-mail address never displayed, HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>