W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2000

Re: "accesskey" - Techniques open issue

From: Gregory J. Rosmaita <unagi69@concentric.net>
Date: Wed, 14 Jun 2000 14:41:06 -0400
Message-Id: <>
To: Wendy A Chisholm <wendy@w3.org>
Cc: Web Content Accessiblity Guidelines Mailing List <w3c-wai-gl@w3.org>
meta warning: most of the URIs contained in this emessage may wrap, 
depending upon your display capacity and modality

aloha, wendy!

since this emessage has grown elephantine, i've divided it into 3 parts:
    Part 1: Threads on ACCESSKEY from UA and IG and Other Pointers
    Part 2: ACCESSKEYs on LABELs -- Implementation Issues
    Part 3: ACCESSKEYs on LABELs -- Testing the Test Page

Part 1: Threads on ACCESSKEY from UA and IG and Other Pointers
there are a few good threads on the topic of accesskeys on the WAI-IG and 
UA lists that may provide us with some fodder for techniques, and some 
clear cut dependencies, some of which wendy has already quoted:

1. my summation of accesskey issues originally made on the 
member-confidential PF list; posted to UA list at the request of jon by 
permission of al and daniel:
and the thread that spins off that....

2. list of threads related to this issue that transpired on the User Agent 
Working Group's Mailing List:

3. Ricardo Sanchez's implementation question on IG:
and the answers he received, including alan cantors:
and (surprise!) mine:

4. my post to the UA list on the irrelevance of the source of User 
Interface (UI) controls

and, of course, there's the HTML4 recommendation's problematic definition 
of accesskey (and expected action upon the triggering thereof)

and the even more (to my mind) problematic approach of the Keyboard Control 
section of the User Interface for CSS3 Working Draft
in which it is expressly stated

The purpose of this property is to be able to specify what key or 
combination of keys being simultaneously pressed activates/triggers a 
particular element. This is typically used to alter the command or control 
key shortcut used for menu items and form buttons. Key-equivalents are 
active in a document only if an element inside the document has the focus 
(this can include BODY). This also applies to documents inside frames. The 
frame must first acquire the focus before key-equivalents for any of the 
elements of its document can be active. There may be platform and user 
agent limitations to key-equivalents which conflict with those inherent in 
the user agent and operating system.
'accesskey' is a symbolic value which represents the default "shortcut" or 
"keyboard accelerator" modifier key for the platform. This value can be 
used essentially the same way that the ACCESSKEY attribute in HTML4 is 
used, to specify a single character to be pressed in conjunction with the 
default shortcut modifier key on the platform.

confusing?  you bet, which is why specifying triggering mechanisms by 
platform specific key-press-combinations that may or may not be present or 
have any meaning on devices capable of accessing the content containing the 
accelerator keys is a very bad idea...

i do dig the part about key-equivalents being active in a document only if 
an element inside the document has focus, but once focus is placed on the 
BODY, there's nothing to keep the key-press-combinations from conflicting 
with the OS or UA key bindings, and the bit about a frame having to have 
focus before key-equivalents for any of the elements of the document can be 
active may lead to replication of key-equivalents slash accesskeys within a 
frameset...  and the quote default shortcut modifier key unquote referred 
to in the preceding quotation should be changed to quote a 
user-configurable triggering mechanism unquote

it's one thing to drive a XUL-like interface using accelerator keys when 
one is programming for a specific platform (which again, to my mind, is a 
mistake) using platform-specific specified keys, but to expect the author 
of a web page to compute (or place his or her faith in the ability of a 
tool to compute) all of the possible combinations for all of the platforms 
and all of the devices upon which the content might be displayed and 
interacted with via some sort of keying device or an equivalent API is 
sheer folly -- a point further underscored by an editor's note preceding 
the list of key-press-combination values defined so far for the User 
Interface to CSS3

Note. Should we include "standard" keys from other consumer computing devices?

Part 2: ACCESSKEYs on LABELs -- Implementation Issues
while i'll try to address as many of the to specific questions raised in 
your post about accesskey -- at least, those that haven't already been 
covered by charles and others (note: the question of dependencies upon the 
UA and PF working groups are specified in some of the above-listed 
posts):as time and my persnickety computer allow, but i will try to answer 
at least one before i send this to the list...

in reference to the question:

The example places the "accesskey" attribute on the LABEL element 
associated with the form control. Is it appropriate for the LABELs to have 
"accesskeys" or should the controls have them?

this is an implementation issue -- the logic behind this expected action 
(activate form control OnClick when a pointing device or equivalent is 
positioned over a label associated with that form control via equivalent 
values for the "for" and "id" attributes) is derived (or so i've read on 
the internet and been told innumerable times) from (of all things) 
usability studies, which showed that users are used to clicking on labels 
to activate form controls in GUI environments...  JFW, the screen reader i 
use most often in the Windows environment, uses screen review commands for 
web-based forms that are identical to those used to query JFW for the 
presence of labels associated with the type of forms one routinely 
encounters in the Windows environment -- the radio buttons, checkboxes, and 
input fields that populate dialog boxes, wizards, and property sheets, so 
it seems logical (at least to me) that a GUI implementation of an HTML4 
compliant browser would activate a form control OnClick of the label 
associated with that control via the "id" and "for" attributes of 
(respectively) the form control and the accesskey...  why?  because giving 
focus to a label associated with a form control via the "for" and "id" 
attributes, is the physical? geographical? point-and-shoot? equivalent of 
triggering the accesskey -- the accesskey has, in effect, been defined 
"for" the input field with an equivalent "id" value...  so, logic (or, at 
least, my logic) dictates, that if you put an accesskey on a label, 
associated with a form control via an "id", it should activate the link... 
the only problem with my logic (at least that i could detect) is that i 
can't independently verify that clicking on a label is the physical 
equivalent of triggering the accesskey associated with a label, which, in 
turn, activates the form control associated with the label...

so, knowing all too well that my logic is far from unassailable, i put as 
much of my logic to the test as i could on your test page,
on which i wish you had listed the accesskeys so that i didn't have to 
resort to the document source to discern them, as neither i, nor my 
computer, were in the mood to play a game of russian roulette with all 26 
possible permutations available in MSIE 5.01, using the tools at hand:

1. MSIE 5.01 (version number: 5.00.2919.6307 with update Versions: 
;q246094;q251109;q240308;q262509) -- MSIE supports accesskey using the ALT 
key in the Windows environment, which leads, as i've noted elsewhere, with 
a few conflicts with some, but not all, default OS menu bindings...

2. JFW 3.50.37, the most current public release of Henter-Joyce's JAWS for 
Windows screen reader, which supports the speaking of labels which are 
associated with form controls when the form control receives 
focus/point-of-regard when JFW is in "Forms Mode"...  in "forms mode", 
labels are usually automatically spoken when tabbed to (try 
<http://www.hicom.net/~oedipus/vicug/ctib1.html#form> for an illustration 
of this if you have access to a screen reader that supports the label 
element, and you'll hear how tricky it is to attach semantically sensible 
labels to most forms if you can't reuse parts of other labels, especially 
when you reach the second checkbox, with its associated -- nay, symbiotic 
-- text input field)

Part 3: ACCESSKEYs on LABELs -- Testing the Test Page
3A) when i first loaded 
<http://www.w3.org/WAI/GL/tests/keyboard-access.html>, i heard:

Keyboard access Example 1 Label 1 edit Label 2 edit submit button Example 1 
survey form that gathers info about how the label and form element were 
read Example 2 Name Favorite food Example 2 survey form that gathers info 
about accesskey on label behavior vs accesskey on form element $Date: 
2000/06/08 15:07:52 $  Wendy Chisholm

3B) when i entered "forms mode" using the CONTROL+INSERT+Home keybinding, i 

         label 1 edit

when i tabbed, i heard

         label 2 edit

when i tabbed again, i heard:

         submit button

when i tabbed to the second form, all i heard was

         submit button

when i queried JFW as to the label associated with the input field (using 
the INSERT+TAB keybinding), all that was echoed was the indication that i 
was in a text input field -- the word "edit"...  using the "Speak Entire 
Line" keybinding (INSERT+UpArrow) all i heard was "edit", so i exited 
"forms mode" (by activating JFW's Virtual PC cursor), but still was unable 
to read the labeled text preceding the input field using the "Speak Entire 
Line" command...  so i routed the JFW cursor (which serves, in a manner, as 
a mouse emulation mode, using gross navigational commands such as up, down, 
left, right, next block element, last block element) to the Virtual PC 
cursor, so that it was aligned with the Virtual PC cursor in the input 
field and issued the "Speak Entire Line" command, only to hear the word 
"edit" echoed...  using the move to next element to the left command 
(INSERT+LeftArrow), the label, "Name", was spoken, but when i executed the 
"Speak Entire Line" command, all i heard was the label text ("Name"), and 
no indication that there was a text input field on the same line as the 
text it had spoken...

3C) using the document source as a guide, i started over from 
scratch...  reloaded the browser; reloaded the page, squelching speech 
using the CONTROL key; and pressed ALT+U, and -- sure enough -- i heard the 
word "edit", so at least i knew that JFW's Virtual PC cursor had been 
placed in a text input field, but without recourse to the document source, 
i had no way of knowing into which input field the focus had been 
moved...  JFW didn't automatically speak the label, as it does when the 
accesskey is associated with the input field, as in the reformatted RFB&D 
form located at:
on which the accesskeys F is known to be broken, as it is the default 
binding for IE's "File" menu...  in this form, i had originally used H as 
the accesskey for the HTML validation button, but ALT+H opens IE's "Help" 
menu, and one annoying example of an implementation bug is enough for any 
live page...  interestingly, as i've pointed out ad nauseam elsewhere 
(refer to the above listed threads if you're not satisfied with the 
catatonic state into which i've induced you), even though the 
accesskey-trigger bindings for the reformatted RFB&D form conflict for the 
IE menu items "Edit", "Favorites", "Tools", and "View", the author-defined 
accesskeys for the accelerator keys defined for the form take precedence 
over the application's default keybindings

anyway, to return to your test page, while the accesskeys worked insofar as 
they placed the Virtual PC Cursor (which, when in a form turns into the 
actual application cursor when you enter "forms mode" by hitting the ENTER 
key), they broke JFW's access to the content of the label associated with 
the input field to which the "for" attribute pointed...  moreover, since 
the label was treated by JFW's Virtual PC Cursor as a distinct element 
(which, in fact, it is), it can't read the line in context, because the 
Virtual PC cursor reads block element that JFW is aware of by block element 
that JFW is aware of, and when it is in the input field, it can't "see" the 
label, although it should be able to associate the text contained in the 
label with the appropriate input element by virtue of the equivalence of 
the value of the "for" and "id" set for each, and automatically speak it 
when the input field receives focus, or when it is queried by the user 
using the "Speak Form Control Label" command...

so, no matter what the answer to the question vis a vis what happens when 
one clicks on a label associated with a form input field, it is still an 
implementation problem...  what i found was simply an implementation 
problem in JFW -- JFW simply doesn't recognize that the "for" attribute 
contained in the label element to which an accesskey has also been bound 
still points to the input element which contains the corresponding "id" 

i would be remiss (especially after calling you to task after sniffing your 
document source), wendy, if i didn't note that this analysis was assisted 
(and expedited) enormously due to my already having had recourse to your 
document source, when i searched it for the accesskeys...  having recourse 
to the document source enabled me to conceptualize the expected graphical 
rendering of the form, based on my browser's settings and twenty years' of 
experience as a hyper-visually oriented individual, including a brief 
flirtation with desktop publishing -- all of which merely serves to 
reenforce my conviction that, while a source view isn't a structured view 
from an accessibility standpoint, i'd never use a user agent that didn't 
offer a document source view -- preferably in the editor of my choice!

so, what's the moral of the story?  if text is associated with a form 
control using the "id" and "for" attribute combination, it should not 
matter whether the accesskey  is explicitly associated with the label 
element or the input element -- as long as it is associated with one, it is 
associated with the other, due to the equivalency of the value set for 
each...  which is, i suppose a dependency on UA...

it strikes me at this late hour (it is now past 5am) that this is the sort 
of relationship that should be expressed in slash obtainable from slash 
possible via the DOM, but i'd have to check to ascertain whether or not it 
actually is or plans to be, or whether it is or isn't obtainable via MSIE's 
COM implementation of the document object model, which is what JFW uses to 
provide linear (and, often, even logical, due to the simplicity of most 
tables used for layout) access to what is otherwise the bane of a blind 
user's existence -- unrelated side-by-side text...  this is an issue which 
a lot of blind users to whom i speak think hasn't been adequately addressed 
in WCAG, because the majority of blind users -- despite the existence of 
things such as extremely expensive GUI screen readers such as the latest 
releases of JFW and Window-Eyes 4.0, Tablin, and emacspeak still hear 
unrelated side-by-side text in one long connected cognitively disconnected 
stream -- much like my posts....

on that note, i'll sign off "shamefully behind in his homework",

ACCOUNTABILITY, n.  The mother of caution.
                         -- Ambrose Bierce, _The Devil's Dictionary_
Gregory J. Rosmaita      <unagi69@concentric.net>
Camera Obscura           <http://www.hicom.net/~oedipus/index.html>
VICUG NYC                <http://www.hicom.net/~oedipus/vicug/>
Read 'Em & Speak         <http://www.hicom.net/~oedipus/books/>
Received on Wednesday, 14 June 2000 14:52:45 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:04 GMT