RE: @key on xhtml2:access still a hot topic

Jason White wrote:
> On Sat, Nov 19, 2005 at 06:12:34PM +0100, Charles McCathieNevile
> wrote: 
>> 
>> On Fri, 18 Nov 2005 16:59:50 +0100, Al Gilman
>> <Alfred.S.Gilman@IEEE.org>
>> wrote:
>> 
>>> ** functional requirements:
>>> Should authors be suggesting key bindings for accelerated functions
>>> in their Web Aps?
>> 
>> Yes. It provides a hint that we (implementors) can use in the absence
>> of
>> better information. John is right that conflict resolution and final 
>> assignment belong to the user agent, and thus so does the
>> requirement to  advertise what actual interaction bindings are
>> available. 
> I concur with Charles. This is a stylistic preference on the author's
> part and should be considered analogous to other presentational
> characteristics that can be specified in styles. The only difference,
> a minor one, is that it concerns input rather than output.   

Jason,

This however is *not* a minor issue.  If the @key attribute were nothing
more
than a hinting mechanism, then perhaps it would be minor.  However, as
currently written and proposed in the XHTML 2 Draft, @key does more - it
binds
a key to a function or role, despite the fact that for any given user,
that
key binding may already be claimed by something else.  This may (and in
the
current implementation of ACCESSKEY currently does) cause end user
issues. This is more
than just a "stylistic" choice - it is a choice which affects user
behaviour and user agent functionality.

>From an accessibility perspective, this causes me great concern.
Absolute key
bindings cannot be 2 things at once, and so for any given time that
there is a
conflict, one of the two "options" becomes disabled.  This may or may
not be
critical, given the dispute resolution process (which is currently
suggested,
but not yet part of the Draft Recommendation).  But I believe I have put
forth
arguments which show that the author's "absolute" ability to enforce key
bindings is wrong, potentially harmful, and ultimately not really
needed,
especially in the semantic markup layer of XHTML 2.  This is and should
remain
a scripting/DOM issue.

Where it also akin to other "presentational" characteristics, end-user
supplied
changes (for example, alternate CSS sheets, or other over-rides such as
text
enlargement within the user-agent), would not break functionality - what
matter
if the text is larger, or the foreground and background colors are
changed for
greater contrast - the content is still accessible.  However, if the end
user
must choose between function A and function B in the document (they
can't have
both, there is only one key), there is a loss of functionality to that
user. Is this
right?

I urge you to visit Accessify.com's web-site here:
(http://accessify.com/preferences/accesskeys/) and see how, within the
current
spec today (never mind the next-generation Recommendation, which is what
we are
talking about) with some intelligent scripting and a little bit of
fore-thought,
the ability for end user key bindings can be delivered, in a way that
the end
user can maintain control over their user agent and system
configuration. THIS
IS SOMETHING THAT ALL ACCESSIBILITY ADVOCATES CAN AND SHOULD ENDORSE -
perhaps
not exactly like this, but this type of functionality - author declared,
user
defined and configured.

There will exist, with ACCESS and @role, the ability for content authors
to
provide the required "hooks" within the authored content for user-agents
to
provide this type of functionality.  All I am saying is that the content
author
should not also be allowed to absolutely bind those hooks to a key.

If, as Accessibility advocates, we know that the statement, "...I *NEED*
to lock
down my fonts to 7.5 px or it will break my layout..." is fundamentally
wrong,
then should not the statement, "... I *NEED* to absolutely bind this key
to
this function or it will break my idea of functionality..." not also be
wrong?

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 Monday, 21 November 2005 12:35:38 UTC