- From: John Foliot - WATS.ca <foliot@wats.ca>
- Date: Thu, 16 Feb 2006 07:46:48 -0500
- To: "'Gez Lemon'" <gez.lemon@gmail.com>
- Cc: <w3c-wai-ig@w3.org>, <wai-xtech@w3.org>, "'WebAIM Discussion List'" <webaim-forum@list.webaim.org>, <gawds_discuss@yahoogroups.com>
Gez Lemon wrote: > On 15/02/06, John Foliot - WATS.ca <foliot@wats.ca> 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 foliot@wats.ca Web Accessibility Specialist WATS.ca - Web Accessibility Testing and Services http://www.wats.ca Phone: 1-613-482-7053
Received on Thursday, 16 February 2006 12:47:15 UTC