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

Charles McCathieNevile wrote:

> Hypertext applications are served to a range of different devices, and
> that range is growing. (Opera alone ships on 6 "desktop" platforms, a
> number of mobile OSes and Opera mini which is customised to a huge
> range of phone, plus a large number of "embedded device" versions -
> TVs, Bar-code scanners, factory-floor special units, etc etc) in
> number and diversity. Basically, they should not make assumptions
> about the delivery context - they might provide some hinting based on
> common assumptions of familiar cases, but they should expect the user
> agent to ignore those hints in the majority of cases, or to use themm
> simply for guidance. 

And here is where Chaals and I differ in perspective.  Given the
diversity of user agents, OS'es, end user configurations, pre-claimed or
reserved keystrokes, etc. how can the author make any kind of informed
assumption about a useful and available key to hint.  I couple this with
the very real concern that since the content author has the ability to
"hint" or propose a binding key, they will extend that ability to the
authored content level (i.e.: help pages, user manual, or "Acc<span
style="text-decoration:underline;">e</span>ssibility").  We know they
*shouldn't*, but we also know that they should always buckle up in the
car, listen to their mother and wear fresh nickers on a first date.
Because content authors *can* however, there is a real chance they will,
and this, IMHO, sets back any benefit that may be derived.

> 
> This is why the rel attribute is good - it doesn't specify what the
> behaviour should feel like, but what its function is, so the user
> agent can provide sommething sensible in the context. It ain't broke,
> but the HTML group thinks that changing it to role would be an
> improvement. There are other ways, I think, but they are on the right
> track. 

Here we agree 100% (and we have been saying so for some time -
http://wats.ca/articles/accesskeyalternatives/52 [Dec., 2003]).  

I maintain that the most important thing the HTML Editors and the WAI
should be looking at is ensuring that the common collection of @role
constructs accurately and fully address the real and "familiar case"
needs of content authors.  With a complete and useful common collection,
user agents can start to natively map keystrokes to these roles - the
actual key may be different across user configurations, but equally,
100% predictable and usable in each set-top, across multiple web
sites/web apps.  I have used this example before:  To get to my IE
favorites (in Windows) I use ALT+A, in Firefox it's ALT+B to access my
Bookmarks.  Conceptually identical, but uses different keys based upon
user agent.  Whether it's the @role collection, or an expanded and well
thought out collection of annotated rel attribute values - if authors
can quickly, predictable and easily author the *intent* of their
keyboard navigation shortcut, and then hand it off to the user agent(s),
then we have improved both accessibility and usability, with very little
to no downside.

> 
> The accesskey attribute (or key, as they would like it to be in the
> brave new world) is a useful hint from an author, taken in context of
> a set of such hints, and used as a guide when there is no rel/role
> information. (Authors who do that should be slapped. Authors of specs
> that encourage that even more so). 

Which is why I advocate that the spec simply remove the ability to
specify the key - remove the possibility and you remove the probability
- no need to slap anyone <smile>.  It forces content authors to
*properly* provide the "hook" to the page location, web app function or
whatever (to propose the *intent* using either rel or role) - they can't
just specify a key stroke and leave it at that.

> That's its place. It isn't
> intrinsically evil, although there are some really counter-productive
> implementations out there. It plays a very useful role in identifying
> that there are some key parts of a page that are probably
> intelligible navigation constructs - "recognisable landmarks". And
> the value inside, the hinted key, may even be useful at times.
> Although that's the least of its benefits, and the thing that has
> caused most of its problems. 

Which of course is why I rail on so much.  It's a balancing act, I agree
- at what point do we stop giving the content author power for fear of
their mis-use of that power?  Chaals references the "recognizable
landmarks" - which I propose be addressed in the common collection of
@roles; done right here it is a simple task for user-agent developers to
provide the internal keystroke mappings, and even, in better tools, for
the end user to customize the bindings if they so choose, to suit their
needs: Opera allows this type of customization already, as does tools
such as WindowEyes, which currently reserves the Numeric hotkeys "...for
User-defined windows".  

Allowing the content author to propose a key however will undoubtedly
also encourage the author to advertise this key in some other fashion -
witness the origin of this thread ("Re: <span> within a word any issue
for screen readers?") - somebody asked about "...Acc<span
style="text-decoration:underline;">e</span>ssibility".  This is why I
cannot support a construct that is both minimally beneficial (even if it
*does* provide some benefit to user agents), and at the same time
provides the most potential for problems - to echo back Chaals' final
statement.

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 Tuesday, 10 January 2006 13:40:18 UTC