This page is best viewed using my browser.
XHTML2 Draft backtracks on accesskeys
The ACCESSKEY element within HTML 4 and XHTML 1 has long been the subject of some argument. Intended as a navigational enhancement for keyboard navigators, it became apparent that, at best, it was shunned by users and, at worst, could cause conflicts with keyboard bindings in other user agents.
For those unfamiliar with the background, I strongly recommend a perusal of John Foliot’s articles on the subject.
Initially, it seemed that XHTML 2 would deprecating ACCESSKEY in favor of the ACCESS element which would allow authors to define access points instead of keystrokes. Keystroke conflicts would no longer be a problem as, within XHTML 2, users could define their own keystrokes. The perennial problem of inconsistent key mapping from site to site would also be removed because the keystrokes would now be defined by the user agent – not the site.
However, the XHTML 2 Working Group is now proposing to add the “KEY” attribute to the ACCESS element – thus, once again, allowing content authors to dictate specific key bindings.
In other words, ACCESSKEY by another name.
The Working Group seem to feel that users need, or want, content authors to control key bindings. I have personally never encountered a single user
who was in favour of author-defined key bindings – let alone felt that they were a user requirement. The users who I have spoken to feel that ACCESSKEY forces bindings upon users whether they want them or not and many users who could, in theory, benefit from single keystroke navigation, ignore accesskeys completely!
I suggest you read John’s response to this proposal and, if you agree with his position, let the Draft Editors at www-html@w3.org know.