- From: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Date: Wed, 9 Apr 2008 08:10:43 -0400
- To: wai-xtech@w3.org
What we presently have in the WAI-ARIA Best Practices draft is pretty negative. <quote cite="http://www.w3.org/WAI/PF/aria-practices/#AuthDefKeys"> Author-defined keyboard short-cuts or mnemonics present a high risk for assistive technology users. Because they are device-, browser-, and AT-dependent, conflicts among key bindings is highly probable. The XHTML 2 Working Group is currently developing a new access element [@@] to address this issue. Refer to Section 9: Implemenation Guidance. </quote> Is there recommendable practice for custom hotkeys from "accessible scripting (before ARIA)" that is acceptable already, now? I don't know whether to take the above paragraph as saying - Don't even think about custom hotkeys, or - wait for <access> to happen .. but I'm not sure we need to say either. My idea of recommendable practice in this area would be roughly like: 1. Every hotkey is menu-backed. For every hotkey that you use, whether by @accesskey or by script, there is a menu equivalent. For @accesskey and <access> we are working on getting this supported in the browser, but for script-enabled hotkeys it is clearly incumbent on the page (or a linked page) to provide orientation to the enabled functions and equivalent-facilitation to these actionss through a menu. 2. The menu alternate for hotkeys is in very robust markup. I don't know how far to go in this regard, but one possibility is that it is all hyperlink-based or possibly a scripted version of the menu is script-substituted for the hyperlink version when the appropriate system support is sensed in the environment. One doesn't have to lard up the page with all these hyperlinks, the menu version of the accelerated actions can be a navigation menu on another page that links back into this page to where the actions are available. The above is rough; I don't have the hand-on experience writing scripts. But I hope the general idea filters through. Questions: Is the "robust menu backup" suggested above doable in a way that does deliver high confidence that the functionality will be available across browsers and OSes? Is it such a bear to code that there is no point in our mentioning it? Is it well covered in some other document or website already? I was interested to read in Colvin and Lysley, "Designing and using efficient interfaces for switch accessibility" <http://tinyurl.com/18r> .. the recommendation that for switch user facilitation, every action in the chrome should have a hotkey equivalent. That seems a strong motivation to support custom hotkeys beyond those for which we can define standard role destinations. And if all hotkeys are backed by menu items in the 'inner chrome' that the application puts in the page, can't we assure access to function for the ones where the acceleration breaks for some reason or other? Is the current best practice for @accesskey useless? Can it be extended in a natural way to cover scripted hotkeys? I know it's not what we want eventually, but what is the currently workable approach? Al
Received on Wednesday, 9 April 2008 12:11:33 UTC