RE: Accesskeys (was RE: Accessibility features)

[Taken public by request]

Jacques Distler wrote:
> 
> Re your previous comments on the <access> element of XHTML2, you
> might want to look at my followup
> 
>      http://golem.ph.utexas.edu/~distler/blog/archives/000727.html
> 
> where I argue that, in XHTML2:
> 
> 1) The role that the definition-list of accesskeys plays in my
> Javascript is played by the collection of <access> elements in the
> document.
> 2) The functionality of my Javascript
>        a) expose the accesskey keybindings to the user
>        b) make the keybindings modifiable by the user
>    ought to be *built-into* XHTML2 User-Agents.
> 
> Of course, this would only work if the <access> element has both a
> "key" attribute (maybe optional) 

Jacques,

With respect, you just said that the functionality of your script would
only work if the <access> element has a @key attribute (but then say it
may be optional).  Which is it?  If it may be optional, then your script
works without it?  If that is the case, why bother declaring a
key-binding that may or may not be appropriate?  This is what I keep
arguing - if @key is an optional attribute, yet authors stand a very
great chance of guessing a key which may conflict with a user set-up,
why bother guessing?  Further, why even allow it?

The proposed <access> element will be, as you noted, paired with a
standardized collection of common @roles.  Since these roles will thus
be "universal" <sic>, browser manufacturers will be able to "embed"
their functionality into their user-agents - no need to "declare" your
list via the source code, the browser has the functionality pre-embedded
into the UI.  I have used the concept of IE's Favorites (ALT+A) vs.
Firefox's Bookmarks (ALT+B) - identical functionality in both browsers,
different keybindings.  But what is important is that the functionality
is persistent and predictable in that user agent, every time.  The end
user does not have to "change" anything, nor "guess" anything, it has
already been "hard-wired" into their respective tools.  At this point it
does not even have to be "discoverable" - if the author has accounted
for the functionality in their code, then the user agent has access to
it, the end. I continue that for most authors, using the common
collection will be sufficient most if not all of the time (and have
further expanded on the fact that we should be looking very closely at
the common collection of @roles to ensure that we have gotten the most
important ones... Already the existing list is missing some key concepts
that perhaps should be added - I am thinking of a direct link to
"Privacy (policy)" for example).

Thus, the only real time an author might move into the area of key
"hinting" is when declaring custom roles.  Again, the addition of the
custom @role replicates your current <dl>, in that it is a (meta)"list"
addition that is subsequently exposed to the DOM, present for scripting.


It is here that the debate of @key focuses:

The "pro" forces argue that providing a hint via @key fills a potential
void, that it would be better to "hint" key="S", rather than key="" (or,
as I suggest, not even declared).  While I can understand this
perspective (nature hates a vacuum), my concern centers on the softer
side of things - authors who "hint" a custom key, choosing "wrong" (i.e.
- specifying a previously claimed key) but then proudly (loudly)
advertising that for function "foo" use ALT+S... (but that is broken in
my configuration...).  

It becomes an issue at the cognitive load level - you tell me that
something will achieve a function, and it either doesn't, or by
following your instructions something different happens.  Now I grant
that this is "extreme", but totally feasible - we "accessibility types"
instinctively know that the following: <img src="" alt="image" /> ...is
wrong, yet a quick google will show that sadly, not everybody
understands.  So while it would be best practices to "not" advertise via
the authored text that "function foo can be accessed via ALT+S", we know
from experience that this will not always be the way.

The "anti" forces (OK, me) thus argues that the equivalent of key="" (or
rather, the lack of a key declaration) will continue to allow the
function to be available to the DOM and scripting, but specifically
leaves the custom functionality key stroke undeclared - open to be
mapped.  I argue that it is far better to then have the author proudly
(loudly) declare that advanced keyboard navigation has been provided,
and may be set by the end user.

It boils down to this: option one results in a potential "undo-redo"
scenario (more often than not?), whereas option two is simply a "do"
(set the key mapping that works best for you the individual user -
perhaps even set it as a persistent cookie, which would be unique for
your set-up, but always available to your default system).  Remember,
this is only for custom @roles - the "standardized" roles have already
been embedded into the UA and mapped that way.  Given the concepts of
"least harm" and "clearest and simplest language" I argue that the empty
keymapping (or rather, the inability for the author to declare the
mapping) is the better choice.

JF
--
John Foliot  foliot@wats.ca
Web Accessibility Specialist
Web Accessibility Testing and Services
http://www.wats.ca   
Phone: 1-613-482-7053

Received on Thursday, 2 February 2006 13:52:49 UTC