Re: Are we really still talking about Access Keys?

At 12:49 PM -0400 6/2/05, Orion Adrian wrote:
>
>I'm personally of the mind that keyboard accelerators should only
>apply to the most common set by default and then be added by the user
>(suggestions are allowed). I can tell you that I'm almost entirely a
>keyboard user and I still don't use keyboard accelerators outside the
>norm. I simply use the menus because they are easy to discover.
>
>What would really be useful is the creation of standard location and
>command sets so that the application can remember usage so that in
>every context that I move to my set of keyboard commands will work. If
>they're domain specific it also allows for a saner environment and
>subclassing.
>
>More on this later as I think about it some more.

Short:
Please consider the factors discussed in:
http://lists.w3.org/Archives/Public/wai-xtech/2004Aug/0011

Long:

One of the half-baked features we put in HTML4 with accessibility in mind
was the 'accesskey' attribute.

http://www.w3.org/TR/html401/interact/forms.html#adef-accesskey

This has had problems in practice, but people still want the functionality.

http://www.wats.ca/articles/accesskeyalternatives/52

Unless persuaded to the contrary, PF is advocating for an approach based
on XML Events (and we think that the impending XHTML 2.0 Last Call
will take this approach).

http://lists.w3.org/Archives/Public/wai-xtech/2004Aug/0011

Declaring an intent-based event identified with the desired outcome still
leaves us with the problem of affording the user an opportunity, some
gesture or range of gestures in the UI, that will allow them to trigger
the intent-based event.

EMMA and sXBL sound like candidates to do the declarative binding of
associations between things that happen in the UI and objects or
event handlers in the document model.

This can be done today by expressing the if X then Y causality in
imperative script code.  But we seek something more declarative.
Some thinking in this regard has centered around sXBL as a way
of binding a UI event to some intent-oriented node.

But at a simpler level, the framework for Multi-modal interaction
will cover, hopefully, the needs of handling alternate
modes of input as configuration options.  The latter case is what
we are trying to institutionalize in replacement for ACCESSKEY.

However, we want to preserve the *author's* access to binding
the events in a provisional way, so that they can create their
own look-and-feel and not be totally dependent on published
conventions.  [The balance here is a matter of contention in the
community.  But the current thinking in PF is that the author
proposes UI bindings, and the User and User Agent may override
these where the user asserts a clear preference.]
http://lists.w3.org/Archives/Public/www-archive/2001Nov/0069.html

Al

Received on Thursday, 2 June 2005 19:42:00 UTC