Re: About accesskey

aloha, ricardo!

in october, i was asked to summarize the problems posed by ACCESSKEY, as it
is defined in HTML4, for the User Agent Guidelines Working Group...  my
summary, which includes suggestions for avoiding the known problems with
ACCESSKEY, can be found at:
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0008.html

before you implement ACCESSKEY (an i _do_ encourage you to do so), there
are a few things that you should know about the current state of support
for ACCESSKEY, and some of the reasons why it has not yet been fully (or
extensively) supported by browsers, despite the fact that acceleration keys
such as those which the author can supply via the ACCESSKEY in HTML4, are
not only the keystone of direct (versus serial) access for any user
interface that supports direct access, but the very principle upon which a
lot of adaptive technology for persons with motor impairments is based...

to my knowledge (and i would be overjoyed if i were to be proved mistaken),
there is currently only 1 browser which supports ACCESSKEY -- MSIE,
versions 4.01 and 5, and both versions of IE do so in different ways...

MSIE5 (running on the Windows platform) uses the ALT key as the ACCESSKEY
trigger, which means that you need to hold down the ALT key while typing
the ACCESSKEY defined for an element, in order to move focus to the element
for which the ACCESSKEY has been defined...  the choice of the ALT key as
the triggering mechanism for ACCESSKEY does lead to conflicts with some
standard Windows keybindings -- particularly, the ALT+F (open File menu)
and ALT+H (open Help menu), but all of the other menu items that are
addressable using ALT key combinations in IE5 -- such as ALT+E (opens the
Edit menu), ALT+V (opens the View menu), ALT+A (opens the fAvorites menu),
and ALT+T (opens the Tools menu) -- do _not_ cause such conflicts...

looking at the issue from a broader perspective, part of the problem posed
by ACCESSKEY,  as defined in the HTML4 spec, is that there is no
normatively defined action that a user agent _must_ perform upon the
invocation of an ACCESSKEY...    this is one of the areas where the HTML4
spec is excruciatingly vague -- quote when a user activates a link defined
by the A element, the user agent generally follows the link. unquote -- so,
while HTML4 doesn't explicitly forbid the UA from only moving the focus or
system caret to the element in which the ACCESSKEY is defined when the
ACCESSKEY is invoked, there is a reasonable expectation that the UA should
activate the element when it's ACCESSKEY is invoked... 

the need for uniform action upon invocation is an issue which i have raised
in several WAI forums, as the user needs to know what to expect when he or
she invokes an ACCESSKEY -- will the focus be moved to the element for
which an ACCESSKEY has been defined, or will activation of an ACCESSKEY
cause the element for which the ACCESSKEY has been defined to be activated
(i.e. the link followed or the form control toggled)?  personally, i would
like the resolution of this question left to the user -- what happens when
an ACCESSKEY is triggered should not only be configurable (i.e. move focus
to the element for which the ACCESSKEY has been defined or activate the
element for which the ACCESSKEY has been defined), but changeable
on-the-fly, as there are cases where one would want to simply refocus the
user agent's point-of-regard upon the element for which the ACCESSKEY has
been defined, and there are cases where one would want the element
activated...  it would also be of immeasurable benefit if the user agent
allowed the user to define the triggering mechanism used to invoke an ACCESSKEY

i have implemented an informal mini-test-bed for ACCESSKEY, illustrating
its use by reformatting 2 existing hypertext forms so that they (a) are
more accessible, by virtue of implementing several of the accessibility
features built into HTML4; (b) illustrate the power and limitations of the
current implementation of ACCESSKEY; and (c) illustrate what i believe is a
necessary authoring practice when one uses ACCESSKEY -- the provision of a
list of the ACCESSKEYs for a document...  the forms are located at:

Search Recording for the Blind & Dyslexic's Catalog
	http://www.hicom.net/~oedipus/books/rfbd_form.html
Universally Accessible RealAudio Download Form
	http://www.hicom.net/~oedipus/ra_form.html

i also implemented ACCESSKEY in the conformance evaluation of HomeSite 4.01
that i performed for the Authoring Tools Working Group
	http://www.w3.org/wai/au/reviews/homesite-19991007.html
in my evaluation, i defined an ACCESSKEY for each guideline, so that the
ACCESSKEY for guideline 1, is 1; the ACCESSKEY for guideline 2 is 2; and so
on, through Guideline 7, the ACCESSKEY for which is 7...  in addition,
there are ACCESSKEYs defined for the Table of Contents (C) and the List of
Guidelines (G)

i should point out that -- due to faulty implementation on the part of IE
-- none of the ACCESSKEYs defined for the conformance evaluation work when
the page is rendered using IE5, despite the fact that the page validates
against the W3C Validation Service as valid HTML4...  the problem seems to
lie in the fact that i defined the ACCESSKEYs in name anchors (i.e. <a
name="gl1" accesskey="1"></a>), which is perfectly valid according to the
HTML4 DTD...  IE also has difficulty with ACCESSKEYs when they are defined
for the AREA element -- something which is also permissible, according to
HTML4... 

here are some supplemental references for you to investigate:
1. definition of ACCESSKEY in the HTML4 Recommendation:
http://www.w3.org/TR/REC-html40/interact/forms.html#adef-accesskey
2. my summation of the ACCESSKEY issue for the User Agent mailing list:
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0008.html
3. my thinking-out-loud about ACCESSKEY post to the member-confidential PF
list: http://lists.w3.org/Archives/Member/w3c-wai-pf/1999OctDec/0065.html
4. my post to w3c-wai-ua on the irrelevance of the source of User Interface
(UI) controls
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0172.html
5. Keyboard Control section of the User Interface for CSS3 Working Draft
http://www.w3.org/TR/css3-userint#keyboard
6. list of threads related to this issue that transpired on the User Agent
Working Group's Mailing List <w3c-wai-ua@w3.org>:
http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0243.html

and, finally, a bit of redundant advice: if you define ACCESSKEYs for a
document, provide a link to a list of the ACCESSKEYs which you have defined
-- ACCESSKEYs (no matter how they are activated) are useless if the user
doesn't know that they exist; therefore, the user needs to be able to
obtain a list of the ACCESSKEYs which have been defined for the document...

i hope that this very brief summary of some of the issues relating to
ACCESSKEY, and the pointers to pertinent references, is of assistance to you...

gregory.

At 01:07 AM 12/10/99 -0500, you wrote:
>Hello.
>
>I would like what criterion you use for the choice the accesskey.
>
>Is it important to avoid the accesskey coincide with
>the browser's accesskeys?
>
>Thank in advance.
>
>Ricardo
>

--------------------------------------------------------
He that lives on Hope, dies farting
     -- Benjamin Franklin, Poor Richard's Almanack, 1763
--------------------------------------------------------
Gregory J. Rosmaita <unagi69@concentric.net>
   WebMaster and Minister of Propaganda, VICUG NYC
        <http://www.hicom.net/~oedipus/vicug/index.html>
--------------------------------------------------------

Received on Friday, 10 December 1999 01:59:27 UTC