WebAIM - Web Accessibility In Mind

E-mail List Archives

Accesskeyus interruptus: another real-world case

for

From: John Foliot - WATS.ca
Date: Feb 16, 2006 6:00AM

Gez Lemon wrote:
> On 15/02/06, John Foliot - WATS.ca < <EMAIL REMOVED> > wrote:
>> More Accesskey news via GAWDS - apologies for those who may have
>> already seen this.
>
> Just to add some context to this: if Accessites had allowed users to
> define their own accesskeys with them disabled by default from the
> start, which is how the technique is supposed to work, there would
> never have been a problem.

Gez,
I don't disagree, and I have commended and complimented you (in
particular) and the others who have moved this concept and function into
the realm of "almost there".

What I found particularly interesting is the "bug" of an upper ASCII
character firing off a form that was not yet completed - I had not
thought of that and it is yet one more strike against author declared
accesskeys (and/or the misguided, continued insistence to perpetuate the
@key attribute in the XHTML2 draft).

As you point out, the script *should* be running in such a way that by
default the specific bindings are undeclared, and the end user is then
free to bind as befits their muse and machine - this *is* the right way
(author proposed, user declared and activated); imagine if next
generation browsers pre-shipped with this type of functionality
(internal scripting?) out of the box. Developers would then simply need
to declare the "hooks" and the browser would take over from there.

Instead, @key will continue to allow for the authors to set up end
conditions such as what Accessites encountered - author declared keys
that introduce usability/accessibility issues from the get-go and
bindings that need to be de-activated or corrected after the fact - an
arse forward system who's lack of logic somehow seems to escape some
people.

This is not a criticism of the Accessites web site, nor the people
behind it (active and involved web accessibility proponents and
advocates), but if developers of this level of activity in web
accessibility are accidentally authoring these types of "errors", what
hope do we have of mainstream, less informed developers "getting it"?
Education can only go so far - sometimes we simply need to take the
sharp scissors away for the better good (which is why I continue to
advocate for the removal of the @key attribute in XHTML2). Scripts such
as yours already show that the *NEED* does not exist, authors can be
given enough control of the situation without having to also declare a
specific key.

Cheers!

JF
--
John Foliot <EMAIL REMOVED>
Web Accessibility Specialist
WATS.ca - Web Accessibility Testing and Services
http://www.wats.ca
Phone: 1-613-482-7053