Thoughts on ACCESSKEY

E. Stephen Mack (estephen@emf.net)
Fri, 18 Jul 1997 04:26:48 -0700


Message-Id: <3.0.3.32.19970718042648.011b9c10@emf.net>
Date: Fri, 18 Jul 1997 04:26:48 -0700
To: www-html@w3.org
From: "E. Stephen Mack" <estephen@emf.net>
Subject: Thoughts on ACCESSKEY

I'm interested in speculation as to how different
user agents should implement ACCESSKEY, especially
in regards to anchors.  IE 4.0 platform preview already
has partial support, so I'll discuss the specification,
how IE has implemented ACCESSKEY, and some questions.

Excerpted from
    http://www.w3.org/TR/WD-html40/interact/forms.html#adef-accesskey
(requoted here for the benefit of those who might
not be familiar with the ACCESSKEY attribute)

> accesskey = cdata 
>      This attribute assigns an access key to an element. An
> access key is a single character from the user agent's
> current character encoding. User agents should treat the
> value of this attribute as case-insensitive. 

So far so good.


> Pressing an access key assigned to an element gives focus
> to the element. The action that is executed when an element
> receives focus depends on the element.  Links defined by A
> are generally followed by the user agent, activated radio
> buttons change values, text fields with focus allow user
> input, etc. 

First of all, more than one element may have been assigned
the same ACCESSKEY attribute value; assumably a user agent
should give focus to the first such occuring element, and
then each subsequent press of the access key will give
focus to the next element with the same ACCESSKEY value.
(Perhaps the TABORDER attribute value could also come
into play.) The HTML 4.0 specification does not address this
issue.

IE 4.0 follows the specification.  It does give focus to a
link with an ACCESSKEY attribute when you press Alt plus the
access key.  Immediately after giving focus, IE follows the
link right away.

If there is more than one element with the same access key,
IE moves the cursor to the next element down, even if the
currently focused element has the same access key.


> The following elements support the accesskey
> attribute: LABEL, A, CAPTION, and LEGEND. 

ACCESSKEY is not listed in the DTD as a valid attribute for
CAPTION, but it is listed as a valid attribute for AREA.
What was the intention here?  Should CAPTION also have
an ACCESSKEY attribute?  Should AREA not allow ACCESS KEY?
I think CAPTION must be mentioned here in error.


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

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

> The invocation of access keys depends on the underlying system.
> For instance, on machines running MS Windows, one generally has
> to press the "alt" key in addition to the access key. On Apple
> systems, one generally has to press the "cmd" key in
> addition to the access key. 

> The rendering of access keys depends on the user agent. We
> recommend that authors include the access key in label text or
> wherever the access key is to apply. User agents should render
> the value of an access key in such a way as to emphasize its
> role and to distinguish it from other characters (e.g., by
> underlining it). 

I'm interested in the conflicts inherent in these last two
paragraphs.  We're told that the user agent decides both
on what the shortcut key will be (depending on the system
used), and that the user agent will render the access key
on screen.  How, then, should an author list the access
key?  "To visit Yahoo, press ALT+Y on Windows or CMD+Y on
Macintosh or simply follow the link if that doesn't work"
is a little unwieldy.  (Maybe I don't know what is meant
by "label text" here.)

IE does not indicate any access keys on screen (at least
as of platform preview one, haven't tried with pp2 yet).

What if I use Z as the access key for anchor text that
doesn't have the letter Z in it?  What should user agents
do to indicate the presence of an access key?  Underlining
seems to be in conflict with the existing standard depiction
of links on a graphical browser.

What's the best way for authors to show which access key
they've assigned?

<A HREF="http://www.yahoo.com" ACCESSKEY="Z">Z: Yahoo!</A>
<A HREF="http://www.yahoo.com" ACCESSKEY="Z">Yahoo! (Z)</A>
<A HREF="http://www.yahoo.com" ACCESSKEY="Z">Yahoo! [Access=Z]</A>

Or should a more explanatory message be used?


-- 
E. Stephen Mack <estephen@emf.net>    http://www.emf.net/~estephen/