RE: Label-for inadequate (was RE: 10.4 Re: Checkpoints 10.4 and 10.5

i had thought that labels would not be needed with option select as the
directions can be included in the option text and this may be true. however,
the title, accesskey  and label aspect would be needed on the command, for
example "State".  so labels would be needed.  i like that i can mouseover a
form control in Internet Explore and it pops up text.

however, the 'for' and 'id' would be needed if tables are used.

-----Original Message-----
From: w3c-wai-ig-request@w3.org [mailto:w3c-wai-ig-request@w3.org]On
Behalf Of Phill Jenkins
Sent: Friday, June 01, 2001 1:55 PM
To: w3c-wai-ig@w3.org
Subject: Re: Label-for inadequate (was RE: 10.4 Re: Checkpoints 10.4 and
10.5


Jim's example [1] is very compelling, simple, yet eloquently conveys the
problem.  However, I believe that the suggested TITLE attribute solution is
just as much a temporary solution as the HEADERS solution.  How will the AT
know the context of when to speak the title and when not too?  always? How
will the author know when to add the title attribute? always?  In Jim's
example, I see the first
field titled as "Taxpayer W2 Gross", and the second field titled "Spouse W2
Gross" and so on so that it is spoken each and every time you visited that
field.  Sounds simple, yet I could also achieve a similar result by using
the headers attribute. But as you pointed out, use [or support] of the
headers attributes [and the title attribute for that matter] varies among
ATs.  For example HPR would only read by default the new or changed header
as the row or column was traversed.  So one would hear something more like
"W2 Gross - Taxpayer,  edit field, Spouse, edit field" which I find less
chatty than the verbose title example.

But the real problem I have with the TITLE attribute solution is that it
prevents the developer from providing a "tool tip" type additional
information, such as "see field x from the taxpayers W2", which is what the
TITLE attribute is spec'd for.

So, the only real best solution is to fix the LABEL spec [2].  We simply
need to be able to have the LABEL element label more than one field. The
spec [2] doesn't explain the restriction, but I could imagine a DOM
developer complaining that he has to traverse the DOM tree looking for new
or changed ID references all the time, or worse yet, the same control
having more than one ID.  It might even be a spec editing problem, meaning
that it should have said that each control can only have one unique id, not
one label.  But in any event, I think the spec should say something more
like -

Phill's proposal:

     The LABEL element is to be used to attach information to controls.
        Each LABEL element is associated with one or more form controls.

     The FOR attribute associates a label with another control explicitly.
        The value of the FOR attribute must be the same as the value of the
        ID attribute of an associated control element. The same LABEL may
        be associated with more than one control by listing multiple IDs in
        it's FOR attribute.  Each control must have only one unique ID.
        More than one LABEL may be associated with the same control by
        creating multiple references to the INPUT's ID attribute via the
        LABEL's FOR attribute.

     example of one label labeling more than one control and one control
        being labeled by more than one label:

<label for="tw2 sw2">W2 Gross</label>
<label for="td sd">Dividends</label>
<label for="tw2 td">Taxpayer</label>
<label for="sw2 sd">Spouse</label>
<input size="20" type="text" title="x in taxpayer's W2" id="tw2">
<input size="20" type="text" title="x in spouse's W2" id="sw2">
<input size="20" type="text" title="y of taxpayers 1099MISC" id=td">
<input size="20" type="text" title="y of spouses 1099MISC" id=sd">

     This example needs some table layout markup added to resemble Jim's
example to make more visual sense, and perhaps a review by a US income tax
web developer <grin/>.  And who knows, we better try the example, it might
even work despite the spec <big smile/>.

The spec should also mention what happens if the HTML is poorly formed.
For example, if the FOR attribute is not unique, drop the next ones; if the
ID is not unique, drop the next ones, etc.

[1] http://jimthatcher.com/simpleformwithtitles.htm
[2] HTML 4.01 Label http://www.w3.org/TR/html4/interact/forms.html#h-17.9

Regards,
Phill Jenkins
IBM Research Division - Accessibility Center
11501 Burnet Rd,  Austin TX  78758    http://www.ibm.com/able

Received on Friday, 1 June 2001 16:06:58 UTC