A very serious concern - Access vs accesskey (was RE: Are we really still talking about Access Keys?)

Tina Holmboe wrote:
> 
>   It's really a case of two issues. First, the implementation. We can
>   all[*] agree that so far a staggering number of user-agents have
>   fouled up in how they implement access keys.
> 

I would agree that we all agree on this

>   The second issue, however, is one of content - and this is where
>   things go wahooney-shaped. We could lobby to have a default set of
>   link types defined so that an UA might give the user access to
>   different links via built-in mechanisms.
> 
>   That would, however, restrict authors to a very limited set of links
>   that could be expected to be recognised - hence access
>   keys, which, in
>   a way, are simply a means to label a link and allow UAs to pick up
>   that label and give access via some sort of shortcut mechanism.

Which is where the newer concept of "Access" comes in.  In the last draft of
XHTML 2, the HTML Working Group envisioned a new attribute called "access"
which would then reference a specific "accesspoint" drawn from a list of
standard accesspoints (for example, 'main content', 'navigation list',
'submit button', etc.).  The concept then was to leave it to the user agents
and users to map *their* preferred/best choice keystroke combinations via
the user agent's settings. (see:
http://www.w3.org/TR/2004/WD-xhtml2-20040722/mod-hyperAttributes.html#adef_h
yperAttributes_access)  There is precedence here: Opera allows a similar
type of functionality; WindowEyes has reserved Alt+1 though Alt+0 for "user
defined" functions, etc..

Sadly, the latest draft (May 2005 -
http://www.w3.org/TR/xhtml2/mod-role.html#s_rolemodule) re-visits this idea,
but moves "access" from being an attribute, to that of an element.  On the
up-side, they have also introduced a new concept, the attribute of "role",
which they envision can come from a list of "standard" roles, or which can
be further defined via RDF, making the "role" attribute infinitely scalable.
This is good.  But when they moved access from an attribute to an element,
they re-introduced the attribute (for access) of "key" (i.e.: <access
key="">).  The intent is to once again give the mapping control to the
author (by, naturally, taking it away from the end user).  This is (IMHO)
very bad, as it is simply "accesskey" in a new set of pants.  And we all
know how I feel about accesskey <grin>.

Seriously, last July we thought that the HTML working group "got it" -
remember, we've always said that the *idea* behind accesskeys was good, it
was just their implementation.  Allowing the end user to decide *how* they
can navigate web content within their user-agent makes sense, and if the
"role" attribute was always there (say, <div role="main_content"> for
example), then if you really want to map that concept to Alt+Ctrl+Shift+Q,
then all the power to you... With the added benefit that for each site that
implements role="main_content" your keystroke combo works!  No more learning
a different set for each site, no more keystroke conflicts (as you get to
choose them, not have them assigned to you), a better system for all!

> 
>   At the moment, accesskey is a way for an author to make a decision
>   regarding his/her content: THIS link is special, THAT link is not,
>   THIS one is definetly special. No UA can make such a
>   choice, unless we
>   restrict content providers to an extreme subset of links.

Which is why the role attribute was/is so brilliant... While we can have a
set of "common" or standard roles, by making the role attribute definable
via RDF you can simply go to town and define as many roles as you want.
True, there would be a practical limit, but the scalability is there.

*****

Truthfully, I only just today noted this change in direction from the HTML
working group, but then again the latest draft is less than a month old.  

However, I am seriously concerned with this new direction... It flys in the
face of the same old arguments we've presented on this list (and others)
since forever.  If you believe, as I do, that giving the mapping back to the
content author is the weak point, that we as content creators should give
the mapping control back to the end user and simply give that user "hooks"
to hang their personalized mapping to, I urge you to make your feelings
known to the HTML working group.  I have already written to them, but many
voices make more noise.

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-267-1983 / 1-866-932-4878 (North America)

Received on Thursday, 2 June 2005 17:10:36 UTC