W3C home > Mailing lists > Public > wai-xtech@w3.org > September 2002

Re: Access Key

From: Jonny Axelsson <jax@opera.no>
Date: Mon, 30 Sep 2002 22:14:00 +0200
To: wai-xtech@w3.org
Cc: "HTML WG" <w3c-html-wg@w3.org>
Message-Id: <B02A8TR07TQ85WQCD874FA8OK75UO.3d98b088@falcon>

Here is a collection of my opinions on accesskey.

It is access *character*, not access *key*. This is what all W3C specs use, 
and the only reasonable alternative when the keyboard vary widely. This is 
different from the OMA (nee WAP Forum) interpretation. They on the other 
hand use dynamic reallocation of accesskey keys, so what the author 
specifies is informative only.

Accesskey will never work unless there is a mechanism to let it be readily 
apparent that a page has accesskeys, and which those are. The suggestion in 
HTML 4.01 (underline the critter) will not work in the general case.

A CSS2 capable browser can simulate the iCab implementation using
  *[accesskey]:after {content: " <" attr(accesskey) ">";}
(this will fail with dynamic reallocation of the accesskey character).

Accesskey should never be allowed to override the keyboard bindings of the 
UA, that would lower accessibility and usability. Since it will be 
unpredictable for the author which keys the UA reserves and what keyboard 
the user has, this implies a separate space for it to be useable.

Conflicts between accesskey and DOM3 text events may still happen, but in 
this case the author will be able to predict the interaction (unless 
accesskey remapping or user overrides are in play), so this is less likely 
to be of a problem. 

I would agree with Tantek on the effect of triggering an accesskey. While it 
is more efficient to do actions with no confirmation, the risk of triggering 
an accesskey accidentally, together with the possibility that the action may 
be irreversible (like a POST or even a GET under some circumstances, or some 
scriptable control), has convinced me that giving the element focus is the 
best and most predictable alternative.

While there are conflicting opinions on whether keyboard navigation should 
trigger events (navigating using a keyboard would normally traverse all 
intervening elements on the way to the target, you would not want to trigger 
those elements), accesskey should trigger a focus event. It is the keyboard 
equivalent to point and click (or rather point and mousedown).

As a conclusion accesskey should be useable and useful. If it offers no 
advantage over alternate approaches it will not be used.

Jonny Axelsson
Opera software
Received on Monday, 30 September 2002 16:06:21 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:51:28 UTC