Re: Access Key

On Mon, 30 Sep 2002, Jonny Axelsson wrote:
>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.

CMN
Agree that it is a character, but it can only be informative given the wide
range of characters and the fact that different systems have a different set
available. (If it takes too many steps to reproduce the character then the
benefit is mostly lost...)

JA:
>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.

Agree

>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).

Because of the likelihood that some dynamic remapping will be required the
browser needs to take responsibility for informing the user what keys are
actually available. Context menus, a link list similar to that used in many
browsers for the HTML link element, a marker in the visual display, are all
possibilities.
JA:
>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).

CMN
For most accesskey users, directly activating links provides the most
efficient and helpful implementation of the functionality. I would recommend
that the default behaviour is instant activation.

I do think it is important to have an option that disables instant
activation, for users who need this. The User Agent Accessibility Guidelines
talks in brief about the general principles in Guidelines 5 -
http://www.w3.org/TR/UAAG10/guidelines.html#gl-user-control-ui

From a personal perspective:

Instantly activating accesskeys are one of the key functions in one of my
everyday browsers (iCab) - much more useful than the ability to tab through
links. But fast keyboard control generally is valuable - structure
navigation, etc - to reduce the strain on my hands of travelling around the
keyboard to use modifiers or sequences, or the mouse.

Accesskeys are better than simple structure navigation because
well-implemented they provide much faster access to the handful of key
elements that will be regularly used. Sites such as http://www.peepo.com try
to make extensive use of accesskey functionality (I believe they still
replicate the instant activation behaviour by using javascript) and for large
or often-used multi-page documents (manuals, big sites, specifications, etc)
they are a well-known usability technique much older than the Web.

cheers

Charles

Received on Monday, 30 September 2002 19:17:42 UTC