RE: labeling controls in tabularized forms (was Re: Proposal for fixing label)

Gregory,

Just a clarification of the example. The fact that my example does not speak
is sort of the problem. Today Window-Eyes will speak all the titles of those
input cells. I have been told that JFW will support titles on input elements
soon; same for HPR. The point is that you can capture the intended labeling
with titles. Phill's proposed change to LABEL (or some variation) is great,
but that is a long term solution. We need a solution today for forms with
complex layouts - not necessarily the simple rectangle of the example.

Jim
jim@jimthatcher.com
Accessibility Consulting
http://jimthatcher.com
512-306-0931

-----Original Message-----
From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org]On
Behalf Of gregory j. rosmaita
Sent: Monday, June 04, 2001 2:44 PM
To: w3c-wai-ig@w3.org
Subject: labeling controls in tabularized forms (was Re: Proposal for
fixing label)


aloha!

PJ: Again, this is trying to solve the problem when you have form INPUT
elements laid out in a table with the "labels" as headings over the columns
or rows. See Jim's example http://jimthatcher.com/simpleformwithtitles.htm

GJR: i did try out jim's example using JFW 3.70.87 and none of the titles
associated with the edit fields were automatically spoken as i tab-navigated
the form -- all i heard was:

	edit box
	TAB
	edit box
	TAB
	edit box
	TAB
	edit box

issuing the "Speak Current Control Label" keystroke command (Instert+TAB)
resulted only in a repetition of the default string "edit box" -- note that
this command works when a LABEL has been associated with a form control

querying the form's control using JFW's "Keystrokes for Working With Tables"
didn't provide any labeling information either:

1. issuing the JFW command for "Say Current Cell", ALT+CONTROL+NumPad5,
whilst in an edit box in thatch's example yields only "edit box"

2. issuing the JFW commands for "Speak Cell to Right", "Speak Cell to Left",
"Speak Cell Below", or "Speak Cell to Right" all resulted in JFW informing
me that i was "not in table"

i've been preparing a few test forms of my own for distribution to the IG
list, in part to discover what works given the state-of-the-art today, as
well as to explore, more fully, the implications of each approach...

the first, tabular_forms_using_label.html, contains three forms, all of
which are extrapolations upon the form which started this thread, the "Web
Search" form located at www.wirednews.com -- they are all rather simple
examples, although with each iteration, the tabularization becomes a bit
more complex...  of the 3 examples contained on the page, only the third is
problematic when linearized...

the second file, tabular_forms_using_label2.html, is a demonstration of a
tabularized table that does not unroll (linearize) gracefully, for whose
form controls both labels and accesskeys have been defined

the third file, tabular_form_using_title_and_alt.html, is a re-iteration of
the form contained in the second file, with all of the LABELs removed --
rather, descriptions have been bound to individual form controls using the
appropriate attribute: ALT for INPUT (as per
http://www.w3.org/TR/html4/INTERACT/forms.html#h-17.4
in which ALT is specifically defined as providing a "short description" for
the SELECT element} and TITLE (as a generic attribute) for SELECT...  as in
jim's example, i find it extremely difficult to obtain any substantive
information from individual form controls using JFW 3.70.47

a few observations/comments on the third file:

3a) ACCESSKEY is not a valid attribute for SELECT...  while, personally, i
believe this to be an error in HTML4, i do think it was a conscious decision
on the part of the HTML WG for 2 reasons:

1. "accesskey" _is_ a valid attribute for LABEL
2. the HTML4 spec states unequivocally at
http://www.w3.org/TR/html4/interact/forms.html#h-17.9 that:

<QUOTE>
Some form controls automatically have labels associated with them (press
buttons) while most do not (text fields, checkboxes and radio buttons, and
menus).
For those controls that have implicit labels, user agents should use the
value of the value attribute as the label string.
The LABEL element is used to specify labels for controls that do not have
implicit labels,
</QUOTE>

3b) JFW's enunciation of descriptions defined using ALT and TITLE is
capricious at best...  in particular, none of the descriptions defined for
the SELECT OPTION controls using "title" are enunciated by JFW -- instead,
only the currently selected OPTION defined for the SELECT control is spoken
(note that, if the "selected" value defined for the SELECT control is
displayed, JFW speaks the "name" defined for the SELECT control as well as
the currently selected OPTION)

3c) using the deprecated U element, rather than a span classed to apply the
text-decoration:underline style rule to the character employed as an
accesskey, to visually indicate the accesskey defined for a form control
minimally improves JFW's attempt to speak a description for the form
control -- consult the fourth attached file:
tabular_form_using_title_and_alt.html

the fifth file, tabular_form_using_label_and_alt.html, employs all of the
methods utilized in the preceding 2 examples: LABEL, "accesskey", "title",
and "alt" -- this is the "hedged-bet" example...  using JFW 3.70.47 to
traverse this form, i hear:

4a) the contents of each LABEL associated with an individual form control;
4b) an indication of the "accesskey" defined for the form control when the
label is spoken after the form control for which it was defined receives
focus (this is not due to the aural styling defined for the
class="accesskey" but a default setting on the part of JFW do indicate
internal anomalies in spelling/capitalization/emphasis within a word)
4c) the default value for the form control with focus

caveats: the first form control -- the "What Do You Want to Find?" edit
box -- has 2 labels associated with it, but only the first LABEL is spoken
by JFW 3.70.47, although sighted users whom i've asked to test these forms
have confirmed that "clicking" on either of the labels defined for the first
form control causes focus to be passed to the form control with which the
label is associated, as per
http://www.w3.org/TR/html4/interact/forms.html#h-17.9.1
which states:

<QUOTE>
When a LABEL element receives focus, it passes the focus on to its
associated control. See the section below on access keys for examples.
</QUOTE>

something which i attempted to signify visually by using CSS to associating
a "dynamic outline" with the LABEL element, as defined at:
http://www.w3.org/TR/CSS2/ui.html#dynamic-outlines
but none of the UAs used to test the forms so far (IE 5x, Mozilla 0.9, Opera
5) seem to support the type of dynamic outlining that would indicate to a
user, OnMouseOver, that the LABEL is an enabled element...

gregory.
------------------------------------------------------------------
ACCOUNTABILITY, n.  The mother of caution.
                       -- Ambrose Bierce, _The Devil's Dictionary_
------------------------------------------------------------------
Gregory J. Rosmaita:                             oedipus@hicom.net
Camera Obscura:           http://www.hicom.net/~oedipus/index.html
VICUG NYC:          http://www.hicom.net/~oedipus/vicug/index.html
Read 'Em & Speak:   http://www.hicom.net/~oedipus/books/index.html
------------------------------------------------------------------

Received on Tuesday, 5 June 2001 13:44:10 UTC