RE: Key bindings... (user agents - was accesskey was ...)

Geoff Deering wrote:
> I'm not disagreeing with anything that you have said, but I think you
> should just take some space to understand the designs that were
> implemented way back in 1999 and the early 2000s, especially when
> people saw the link between accelerator keys in GUI design and
> accesskeys. 

Geoff, I understand what you are saying, and I don't disagree with your
point.  I've been developing sites since the late 90's and have been
doing the "accessibility" thing since about 1999.  I too used accesskeys
in my designs back then, and extolled the virtues and benefits of
providing enhanced keyboard based navigation at that time.

Then I actually started working with blind users and other users of
Adaptive Technology, and started noticing a very disturbing fact -
accesskeys weren't working the way they were envisioned - in fact they
were horribly broken.  So we started talking about it, and tried to
educate people on the problems.  The first WATS.ca article about the
subject was written back in May, 2003, based upon initial research we
did in the fall of 2002, and based upon that research was instrumental
in getting the Canadian government to re-think their strategy regarding
accesskeys.  In the end, they actually reversed their requirements and
removed the mandate to use specific accesskeys on Gov. of Canada web
sites.  Since then, both Derek Featherstone and I have sought to educate
and inform on this topic - but we have never chastised:

	Using Accesskeys - Is it worth it?: 
	http://www.wats.ca/articles/accesskeys/19

	More reasons why we don't use accesskeys: 
	http://www.wats.ca/articles/accesskeyconflicts/37

	Accesskeys and Reserved Keystroke Combinations: 
	http://www.wats.ca/resources/accesskeysandkeystrokes/38  

	Link Relationships as an Alternative to Accesskeys: 
	http://www.wats.ca/articles/accesskeyalternatives/52

	The Future of Accesskeys: 
	http://www.wats.ca/articles/thefutureofaccesskeys/66 

	Access + Key still = Accesskey: The XHTML Role Access Module
still flawed:
	http://www.wats.ca/articles/xhtmlroleaccessmodulestillflawed/80 

> Please don't go jumping all over these people, as the way
> you present your case seems to me that you don't really understand
> the path they took to implement these designs, all in good faith that
> they were enhancing accessibility and usability.  

Please do not misconstrue my current rants as being admonishment of past
sins.  We all do the best we can at the time, and if we later learn that
there is a better way, and adopt that better way moving forward, then
all is good. Today, most developers who care about accessible design are
aware of the issues surrounding accesskeys, and I am proud of whatever
small part Derek and I may have played in moving that education forward.

I personally have abandoned any hope of ever really seeing the accesskey
attribute being repaired to a usable state - although I was blown away
by Gez Lemon's script(s)
(http://juicystudio.com/article/user-defined-accesskeys.php).  For while
I am probably best known for my stand against accesskeys, I have also
always stated that I support both the need and benefit of providing
easier keyboard navigation, which I concede is something that the
content author can and should provide; it's the current methodology that
I decry.

However, these days I reserve the bulk of my discourse for the current
Draft XHTML 2 document, which continues to advocate the author ability
to specify a specific key for binding.  I argue that it is wrong, and
that it needs to be re-thought - the content author does not need this
ability - allowing them to do so introduces more potential problems then
it resolves.

If you look at the previous draft (the one referenced in the article
"The Future of...") the editors at that time had proposed setting a new
attribute of @access, which would have provided the "idea" behind the
target, but left the binding to the user-agent.  Over at WATS.ca we also
had discussed modifying the REL attribute (see: Link Relationships as an
Alternative to Accesskeys), or at the very least expanding the existing
"pre-approved" REL values (types)
(http://www.w3.org/TR/1999/REC-html401-19991224/types.html#type-links).
(Chaals McCathieNevile, and I, still think that using REL is a smart way
to go - we actually agree on more than we disagree on, and we are
friends as well BTW).

But then, in the latest draft the Editors took, in my very humble, but
(if I am to be honest) fairly informed opinion, a step backwards when
they once again suggested providing a means for the author to bind a
specific key. This prompted me to make an official comment to the Draft
process, and subsequently also post my concerns at WATS.ca.  And while
my position seems to have gained some traction within the "rank and
file" (those of us in the trenches), I have not yet been able to
convince the Editors to eliminate the newly proposed @key attribute
(yet).  

So I continue to try and explain what I see are the issues, and
hopefully gain more support for my position - if authors are provided a
means of declaring the intent, the hook, the location, the "idea", then
it should subsequently be the responsibility of the user and their
user-agent to provide the final binding.  Go to the WAI list archives
and search by my name - I've spilt gallons of digital ink on the topic
so far, and so if my tone is starting to sound exasperated, well...
(sorry)  It's about the author giving up some control - a position I
understand is difficult.  But web developers have had to understand
giving up other forms of control in the past - witness fluid layouts and
scalable font sizes.  If the system of declaring access points is robust
and well thought out, authors will not miss the ability of declaring a
specific key any more than most developers today miss using the font tag
or absolute font sizing.

> But as one of them,
> I thank you for all the issues that you have raised to help broaden
> the discussion and education on this issue, and that a better
> approach to this is offered because of these discussions.
> 

Well, thanks for that Geoff, it is appreciated.

Cheers!

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 Wednesday, 11 January 2006 20:19:47 UTC