Re: Access Key

Accesskeys are important for allowing direct navigation to links and form 
controls, especially web based applications that people use on a daily 
basis.  When I use accesskeys I always provide built-in documentation to 
what accesskeys are available in addition to the underlining technique of 
the key letter in the link or form label.  We have developed a web based 
database to keep track of disability services here at UIUC that uses 
accesskeys and works very effectively to speed navigation for screen reader 
users.  We have a internal link on each page to a list of the available 
accesskeys on the page[1].

My criteria for accesskeys:
1. There must be a mechanism to allow all accesskey assignments to be 
triggered by the user.
2. Accesskeys that conflict with user interface controls still need to be 
made available, maybe through a extra modifier key (alt+control+Accesskey 
on windows and LINUX on PC hardware)
3. I think moving focus is better than automatic activation (the IE rather 
than NN way)
4. They should not trigger keyboard events, just like keyboard short cuts 
for user interface elements do not trigger events (i.e menu pull down)
5. User agents should implement a function that allows the user to query 
the user agent to the available accesskeys in a document.  Maybe generate a 
list, like Opera does for Links.

Jon

[1] https://itaserv.rehab.uiuc.edu/accesstrak (login:guest, password: guest)

At 10:14 PM 9/30/2002 +0200, Jonny Axelsson wrote:

>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
>Documentation,
>Opera software

Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
MC-574
College of Applied Life Studies
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL  61820

Voice: (217) 244-5870
Fax: (217) 333-0248

E-mail: jongund@uiuc.edu

WWW: http://www.staff.uiuc.edu/~jongund
WWW: http://www.w3.org/wai/ua

Received on Tuesday, 1 October 2002 10:37:00 UTC