- From: Gregory J. Rosmaita <unagi69@concentric.net>
- Date: Wed, 14 Jun 2000 14:41:06 -0400
- 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:
<http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0008.html>
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:
<http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0243.html>
3. Ricardo Sanchez's implementation question on IG:
<http://lists.w3.org/Archives/Public/w3c-wai-ig/1999OctDec/0721.html>
and the answers he received, including alan cantors:
<http://lists.w3.org/Archives/Public/w3c-wai-ig/1999OctDec/0723.html>
and (surprise!) mine:
<http://lists.w3.org/Archives/Public/w3c-wai-ig/1999OctDec/0725.html>
4. my post to the UA list on the irrelevance of the source of User
Interface (UI) controls
<http://lists.w3.org/Archives/Public/w3c-wai-ua/1999OctDec/0172.html>
and, of course, there's the HTML4 recommendation's problematic definition
of accesskey (and expected action upon the triggering thereof)
<http://www.w3.org/TR/REC-html40/interact/forms.html#adef-accesskey>
and the even more (to my mind) problematic approach of the Keyboard Control
section of the User Interface for CSS3 Working Draft
<http://www.w3.org/TR/css3-userint#keyboard>
in which it is expressly stated
quote
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.
[snip]
'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.
unquote
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
quote
Note. Should we include "standard" keys from other consumer computing devices?
unquote
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:
quote
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?
unquote
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,
<http://www.w3.org/WAI/GL/tests/keyboard-access.html>
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:
quote
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
unquote
3B) when i entered "forms mode" using the CONTROL+INSERT+Home keybinding, i
heard:
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
edit
edit
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:
<http://www.hicom.net/~oedipus/books/rfbd_form.html>
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"
value...
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",
gregory.
-------------------------------------------------------------------
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 UTC