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

Richard Schwerdtfeger wrote:
> Hi John,
> 
> The key bindings are left to the end user if they wish. They are not
> required. 

Please re-read my numerous postings.  I have specifically suggested that
they *NOT* be required (further, not allowed!) by the author, as it
perpetuates one of the basic issues/problems that accesskey produced,
chiefly being that lack of standardization.  If end users cannot be assured
that the bindings are the same on each site they visit, they become less
than useful.  You may choose "S" for search, but I choose "Q" (based upon
'query', as "S" is currently over-ridden by IBM HPR and my Sage News Reader
extension in Firefox), and Manuel chooses "B" for Búsqueda.  The end user
then has no idea which is 'right' or correct.  This also can be an issue of
concern for internationalization, as not every keyboard out there has an "S"
key or a "Q" key or a "B" key.  What then?


> Additionally, the author may not wish to do the key
> assignment and in these cases they may be left to the browser. You
> have ask yourself:   
> 
> - Do all cell phones have a keyboard?
> - Will the same keys be available on Linux and the Mac as on Windows?
> - Can I use the same keys in IE and Firefox?

Exactly.  So stop declaring the bindings!  Declare the intent and leave the
binding assignment to the end user.  I'm not sure if you have understood my
point, as all of these possibilities lead to other reasons why specific
bindings (as declared by the author) are foolish at best, harmful in
extremes, and useless as often as not.  Removing the authors ability to do
so does not cause any "harm" that I can see (or that has been adequately
defended).

> 
> The cost of requiring the user to predict what key to use on every
> device is not acceptible. XHTML 2 will be used for other environments
> than just the desktop.  

Right - this is exactly what I am saying.  The current suggestion that users
be allowed to "over-ride" author specified bindings is arse forward.  As the
Al Gilman posting re-counted: 

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

The tail is wagging the dog!

> 
> As to why it is an element vs. an attribute: Access key, as it is
> today is non-deterministic. The author now has the ability to define
> which event gets generated (focus or activate) as an example. We also
> wanted to allow for role based navigation. We wanted to provide a
> title attribute to describe the action. There are only so many things
> you can attach to a single attribute.   

Good sir, have you not read my suggested solution?  It addresses role
('standardized' or user defined), role based navigation (extensibly), title
attribute, and more.  I have asked *why* this way forward would not address
the concerns and intent that all are striving for.  Again, for the record:

A) W3C has a 'standard' list of common roles (as per Draft 20050505)
 
B) Custom 'roles' are defined via RDF
 
C) "Access" becomes simply a meta element (akin to link) so that when
defining custom 'roles' it can be auto-discovered by user-agents.  This type
of function already exists in "auto-discovery" RSS feeds.  <access
role="disclaimer" rdf.resource="">. Admittedly, this is the weakest link in
my proposal, however I do not think this outside the realm of possibility. 
 
D) "Role", as an attribute, becomes the intent declaration.  Like other
attributes (lang, title, class, etc.) role can then be applied to any
semantic construct: <p role="disclaimer">.  Good UI's will then "announce"
when a custom role is present and allow the user to bind (or ignore) on a
case-by-case basis. (perhaps the "title" attribute would also be required to
give the role a human readable identifier?)
 
E) Binding is left to individual user-agents / user preferences. This does
not preclude any user-agent from providing a "default" key binding within
their UI to the list of 'standard' roles defined and published by the W3C. I
will point specifically to Opera as a tool that demonstrates this type of
function, allows this, and allows end users-to re-map via the UI directly
(not by fiddling with alternate style sheets, userJS, or other arcane,
"geeky" methods).  As has already been pointed out, this is not realistic
either.
 
The net effect here is that, by and large, those developers that you are
seeking to "carrot" get their functionality without having to "guess" at
appropriate keystrokes, the majority of end-users have a stable, learnable,
reliable and CONSISTENT method of invoking keyboard navigation, yet
customization of key-bindings is left directly with the minority of end
users if and when required.  The content author never had a say in it.
  
> 
> In short, the original access key was designed with very little
> foresight as to where the industry would go. The new access element
> is designed to address semantics navigation, device independence, and
> flexibility on behalf of the author while providing a degree of
> backward compatability.    

With due respect and humility, you are preaching here to the converted.  A
quick review of the WAI-IG archives will show you that I have screamed,
ranted and bemoaned this fact for years now, both on the WAI-IG list as well
as other accessibility discussion lists (WebAIM, GAWDS).  My associate and I
have written extensively on the subject - start here:
http://wats.ca/articles/accesskeys/19.  I honestly do not think that the
current proposal in XHTML 2 Draft 20050505 adequately addresses the primary
issue of 'behaviour vs. intent'.

> 
> Hopefully, this addresses the issues you raise.

Sadly, not in the least.  I have argued that the author must not have
control over the end user's behavior norms, and allowing the content author
to bind *their* idea of what is 'best' is wrong; it flys in the face of
numerous other ideals and precedents, all of which I have referenced in my
last posting.  Nothing you have replied with addresses this concern, nor
even attempts to adequately refute my alternate proposal.

Sincerely,

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 Sunday, 5 June 2005 01:12:15 UTC