W3C home > Mailing lists > Public > www-html@w3.org > June 2005

Re: Are we really still talking about Access Keys?

From: Al Gilman <Alfred.S.Gilman@IEEE.org>
Date: Thu, 2 Jun 2005 15:39:29 -0400
Message-Id: <p06110406bec50c751026@[]>
To: www-html@w3.org

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
>More on this later as I think about it some more.

Please consider the factors discussed in:


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


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


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).


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.]

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

This archive was generated by hypermail 2.4.0 : Thursday, 30 April 2020 16:20:57 UTC