RE: Are we really still talking about Access Keys?

Charles McCathieNevile wrote:
> Summary: Accesskeys are a good idea. Bad implementation both
> in the spec
> and in browsers makes them less than they should be, and can cause
> problems, but I still like being able, as an end user, to use
> them. 

Chaals,
To be more specific, you like the ability to navigate a web page using
keyboard commands and keystroke combinations.  Fair enough, I've never said
that this was not a laudable goal or a great idea.

> (Use
> the rel attribute first, where there is a rel defined for
> what you are
> trying to do, though).

Which we've suggested. I've even suggested that more "standardized" relative
links be endorsed by the W3C, which in a circuitous route they sort have
done, with the "roles" being defined for the new "access" ELEMENT (see my
other rant of the day -
http://lists.w3.org/Archives/Public/w3c-wai-ig/2005AprJun/0350).

> 
> Yes, as an end user I REALLY appreciate them when I have an interface
> that makes them work. 
<snip>
> Opera's interface allows me to do lots of really useful
> things with the
> keyboard, so requires a trigger key for accesskeys. The only
> thing I need
> is to know which accesskeys are available (there are a couple
> of different
> ways to do this, by the way - style sheets, or userJS seem the most
> obvious candidates. I lean towards userJS because it makes it
> easy enough
> to remap the keys to suit me, 

In other words, Chaals must now over-ride the instructions implemented by
the author - in effect creating his own mappings.  The XHTML 2 draft of July
2004 introduced the idea of the "access" attribute, which we applauded, as
it created the "hook" that keyboard navigators required, but left the actual
mapping to the end user.  Smart... With that system, you could in effect map
the same keystroke combination (to say "navigation") to work on *all* sites
that simply identified said section as <.. access="navigation">.  No fancy
UserJS sniffing, sorting, re-mapping required. Set it/them once in your
user-agent and then sit back and use them - consistently and predictably.

> 
> And we, as in you and I, have argued this back and forth...

Actually I am fearful that I am beginning to sound like a one-tune fiddle,
but I still will defend my position.  And for those that care, Chaals and I
are (I hope) friends... We've drank together if that is any indication
<grin> (http://flickr.com/photos/derekfeatherstone/2693284/).

> 
>> * We've argued against them from the perspective of technology
>> (conflicts, conflict resolution, etc.);
> 
> Yes. Since they are normally overridden, it seems not to be a
> big deal.

Well... I have put forward the idea that "broken" behaviours, (especially
when "advertised") may cause an issue with those with some forms of
cognitive disability.  It's thin, I agree, but not outside the realm...

> UBAccess' pagemap provided a nice way of putting them in or
> taking them
> out, having customised them to your own needs. That's the
> kind of approach
> that I hope to have in userJS although that will be an Opera-specific
> repair for the page - the benefit of a server-side solution
> was that it
> worked for all browsers.

And so, for now, it will be a one browser solution?  What ever happened to
user agent agnostic?  And Chaals, you chose the word repair, not I.  They
will still be broken (as in, not repaired) for most other users, no?

> 
> 
> There is a group in WAI called the Protocols and Formats
> group. That group
> has worked on trying to get a decent solution to accesskey in
> other W3C
> specifications, and it seems likely that XHTML 2 will in fact have
> something similar but smarter...

Yes kids, wait for it: <access key="S">  IMHO, this is just as useless as
<.. Accesskey="S"> as it still gives the author control over the end user's
outcomes.  Oh, they recommend that a means should be provided to allow the
end user the ability to over-ride the authors binding, but that sort of
sounds a little "close -the-gate-after-the-horse-has-escaped" to me,
especially since previously (Draft 20040722) they were talking about letting
the end user map their own bindings.  Now users must explicitly over-ride
the (unknown) author's bindings.  Why is the W3C placing the burden on the
end user?  How can this be seen as improving accessibility?

> 
> I do not believe that accesskeys are very relevant to blind
> users. 

Did I say blind users anywhere? Re-direct... 

> They
> will in some cases learn them for frequently visited sites,
> if they get a
> decent implementation to start with, 

...and I am becoming more and more disillusioned that this will ever happen.


> but for the most part
> they won't. On
> the other hand for various groups of people who type, and
> have problems
> with their hands, accesskeys are important. 

Fair enough.  But how do *you* know which keystroke combinations are
acceptable for these users, and which ones may cause more grief than
resolve?  Earlier, you spoke of using userJS to seek out and then re-map
such bindings to suit *your needs*.  Chaals, you are very tech savvy, and so
are able to do this type of thing. Will all of the others that may benefit
from keyboard mapped navigation be as adept? Why not just let *them* decide
from the on-set, rather than try and figure it out as they go? Most users
don't even know or understand about user style sheets, or how to change
them.  You want them to now start figuring out how to map alternative
keystroke bindings?  Who here thinks this is realistic?

> Which makes it
> all the more
> frustrating that they are so badly implemented in some browsers that
> people like John have a reasonable argument for suggesting
> they should be
> avoided.

Chaals, I've said it every time I've argued for not using Accesskeys.  The
idea is great, but propping up flawed implementations is self-defeating and
wrong.  Fight instead for scalable, usable, user-control-able key mappings
and accept nothing else.

> 
> (Please listen to my even more reasonable argument, not
> John's, and use
> them in your sites. This makes it easier to argue for effort
> being spent
> on better implementation in browsers, which will make them
> serve better
> the goal they were designed for... :-)

...Or disagree with Chaals and join me to try and make the W3C see the
light.  The idea of assisting users who employ keyboard navigation is great,
THE PROPOSED SOLUTIONS ARE STILL WRONG.  

Go back to the thinking that was emerging in Draft 20040722.  Or perhaps
drop the "access" attribute and/or element all together and support a
strong, robust "role" attribute, which could then be mapped-to by the user
agents.  

But at all costs, leave the mappings to the end user.  Authors *MUST* stop
trying to decide for the end user what is best.  And *THAT* is one
Accessibility Rule I will never back down from.

> 
> cheers
> 
> Chaals

Backatcha!

JF

Received on Friday, 3 June 2005 03:48:18 UTC