accessible custom hotkeys

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