Access Element is WRONG (was RE: Are we really still talking about Access Keys?)

Al Gilman wrote:
> 
> 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.

By creating an element known as "access" and giving it a possible attribute
of "key"?  You have got to be kidding.
(http://www.w3.org/TR/xhtml2/mod-role.html#s_rolemodule)

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

This is, frankly, poppycock.  The real question is *why*?  By preserving
this capacity for explicit binding you perpetuate the basic problem that
exists with the current accesskey - lack of standardized keys, pre-claimed
and conflicting key bindings for various user-agents and adaptive
technology, etc., etc.  

I like "Role", I like the pre-determined list of common roles and the fact
that role is extensible via RDF.  Leave it there.  Let the users determine
the how and what. Never mind letting the author "guess" which key is most
appropriate.  I honestly thought that we had gotten past "look" as a
criteria, leaving that to CSS.  (Besides, doesn't the RDF extensibility of
Role extend it beyond the "common 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


If the WG feels that having the "key" attribute is important, why are you
deprecating accesskey?  What, honestly and truthfully is the difference
between:

 access key="S"  and  accesskey="S" 

...outside of the fact that one is an attribute, the other an element?  Both
bind that particular "thing" to "S", whether or not "S" is already claimed
by something else on my configuration or not.  It does not solve many of the
inherent problems currently experienced with accesskey.  So why bother?  

To further state that user agents and/or end users should then somehow be
allowed to explicitly over-ride the author's binding... C'mon... 

How did all of this:

<q>The user has better knowledge of what works for them and what does not
than an author trying to prepare an experience for multiple users.

{plus}

Users quite generally prefer not to change the author's presentation or
UI design, and to change it as little as possible where necessary.  Most of
the people using something other than the default presentation or input
binding the author offered are people who need to use something different.

{and finally}

When there are many settings associated with adapting a user interface,
the user may not be able to navigate the interface state to an optimum.</q>
(http://lists.w3.org/Archives/Public/www-archive/2001Nov/0069.html)

...end up like this:

(The Draft states:) "Note. Authors should consider the input method of the
expected reader when specifying an accesskey." Plus the brilliant: "User
agents should render the value of an access key in such a way as to
emphasize its role and to distinguish it from other characters (e.g., by
underlining it)."  [Let's be sure to let all our blind friends over at WAI
know to watch out for an underlined letter, OK?]
(http://www.w3.org/TR/xhtml2/mod-role.html#s_rolemodule)

That's a lot to put on the end user, all for the benefit of some
Photoshop/Dreamweaver jockeys who want to preserve their "look and feel"...

We've already seen, first hand, what happens when well meaning but poorly
informed authors impose what they think is best; You get entities such as
the UK government *mandating* an accesskey of "S" to be bound to "search",
despite the fact that a tool like IBM HPR uses the same keystroke (ALT+S) to
get to user settings! (http://wats.ca/resources/accesskeysandkeystrokes/38)
Why even give them the opportunity to mess things up?  

How did this come to pass?  In Draft 20040722 (http://tinyurl.com/797na) you
guys had it right, one draft later it's gone to being yet another useless
oddity ripe for abuse.

THIS IS JUST PLAIN WRONG!

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

Received on Thursday, 2 June 2005 21:06:46 UTC