E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 2 (In chronological order)

From: John Foliot - WATS.ca
Date: Thu, Feb 16 2006 6:00AM
Subject: Accesskeyus interruptus: another real-world case
No previous message | Next message →

Gez Lemon wrote:
> On 15/02/06, John Foliot - WATS.ca < = EMAIL ADDRESS 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 ADDRESS REMOVED =
Web Accessibility Specialist
WATS.ca - Web Accessibility Testing and Services
http://www.wats.ca
Phone: 1-613-482-7053

From: Daniel Champion
Date: Thu, Feb 16 2006 7:45AM
Subject: Accesskeyus interruptus: another real-world case
← Previous message | No next message

JF wrote:

>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"?

In this particular instance I have to hold my hands up and say "mea
culpa", since I set the defaults for Accessites. That said I was following
the oft-quoted UK government standards for accesskeys [1], in the
misguided belief that they were reasonably unobtrusive.

Clearly they don't cut it - any UK government site adhering to the
standard has the potential to cause problems, since "0" is the default
accesskey for accessing 'Access key details'.

For UK government web people like myself it now comes down to a decision
of which is the lesser of two evils - not adhering to the standard,
therefore denying those who use accesskeys easy access to the accesskey
details for a site (not to say incuring the penalty of a poor SiteMorse
report), or adhering to it and potentially incoveniencing users who
require to enter accented or other extended characters into forms?

Personally I've gone for the former - it's relatively easy to find
accesskey information without the default being set, while the potential
frustration of being whisked away from a partially completed form is
somewhat more problematic IMHO.

Dan

[1]
http://www.cabinetoffice.gov.uk/e-government/resources/handbook/html/2-4.asp#2.4.4




This email and any attachments have been scanned for viruses prior to leaving Clackmannanshire Council.

Clackmannanshire Council will not be liable for any losses as a result of viruses being passed on.

www.clacksweb.org.uk