Re: Access Key (and proposed HTML4 erratum)

Steven, Wendy,

Thanks for bringing up and furthering this discussion.

This (the lack of clarity on what an accesskey does on a hyperlink) has been
an issue for us (Microsoft).

IE/Windows takes the more conservative approach of *not* activating, and
just focusing the hyperlink.  This allows for better handling of duplicate
accesskeys for example, e.g. focus to the first element that has the
accesskey after the currently focussed element, thus you can "cycle" through
such elements by continuing to press the same accesskey.

IE5/Mac took the more literal approach of what was implied by the HTML4 spec
of activating the link (as it says in the example).

 http://www.w3.org/TR/html401/interact/forms.html#access-keys

================
In this example, we assign an access key to a link defined by the A element.
Typing this access key takes the user to another document, in this case, a
table of contents.


<P><A accesskey="C"
      rel="contents"
      href="http://someplace.com/specification/contents.html">
    Table of Contents</A>
================

Since this is only stated in the spec as part of an example, it is
informative (not normative).  However, there is a definite direction of
implementation implied by the spec, so while filling out our HTML4
implementation in IE5/Mac, we took it.

But it has been perhaps three years since I took that interpretation, and
have realized that not only is it
 a) inconsistent between our products, but also
 b) inconsistent among elements (other elements focus rather than activate)
 c) disadvantageous to handling duplicate accesskeys
 d) disadvantageous for accessibility from the perspective of the
possibility that a hyperlink is activated by the user accidentally without
first being able to see (via the transfer of the focus) what hyperlink they
are activating.


Thus I now tend to agree with Masafumi Nakane [3].

Personally I would like to see that section of HTML4 errata'd

from:

=======
Typing this access key takes the user to another document, in this case, a
table of contents.
=======

to:

=======
Typing this access key focuses a hyperlink to another document, in this
case, a table of contents.
=======


Since this is merely a change to an informative example, this shouldn't be
considered a change to the conformance/functionality of HTML4 and hopefully
can be made easily.


Thanks for your consideration.


Tantek



On 9/27/02 10:37 AM, "Wendy A Chisholm" <wendy@w3.org> wrote:

> 
> Steven,
> 
> Looking on the WAI lists, I see a variety of responses, particularly in the
> thread started by Aaron Leavanthal on 24 April 2001. [1]
> 
> For example:
> Gregory Rosmaita thinks it should be user configurable. [2]
> Masafumi Nakane thinks we should take a conservative approach and *not*
> activate. [3]
> Kelly Ford makes a distinction between a button (activate) and a link
> (focus). [4]
> 
> I would ask the UAWG.  They have a variety of test suites for accesskey
> [5,6] and UA behavior is the primary topic of UAAG.
> 
> --wendy
> 
> [1] http://lists.w3.org/Archives/Public/w3c-wai-ig/2001AprJun/0241.html
> [2] http://lists.w3.org/Archives/Public/w3c-wai-ig/1999OctDec/0725.html
> [3] http://lists.w3.org/Archives/Public/w3c-wai-ig/2001AprJun/0274.html
> [4] http://lists.w3.org/Archives/Public/w3c-wai-ig/2001AprJun/0253.html
> [5] http://www.w3.org/WAI/UA/TS/html401/cp0101/0101-ACCESSKEY.html
> [6] http://www.w3.org/WAI/UA/TS/html401/
> At 10:52 AM 9/27/02, Steven Pemberton wrote:
> 
>> Editing the XHTML 2 spec, I came across something I wasn't sure of.
>> 
>> If an access key is on a link, should the access key take you to the link,
>> where you must then activate the link (with return or space or whatever), or
>> should it immediately follow the link.
>> 
>> HTML 4 says follow the link, but I note that UAs aren't consistent here. My
>> personal feeling is that the link should get focus, so that you can then
>> decide what to do with it, but I'd like to hear from WAI people.
>> 
>> Thanks!
>> 
>> Steven Pemberton

Received on Friday, 27 September 2002 15:58:07 UTC