- From: Gregory J. Rosmaita <unagi69@concentric.net>
- Date: Fri, 10 Dec 1999 02:05:01 -0500
- To: Ricardo Sanchez <rsv@retemail.es>
- Cc: WAI Interest Group Emailing List <w3c-wai-ig@w3.org>
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