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

Although not perfect, one solution for the use of Title at this time is to
include the naming and additional information as part of the title tag.

For example if you have an edit box with a title of first name, the title
for the edit box might be first name: 20 characters max.  This assumes
that you want to inform all users of the max characters that can be
entered as the tool tip.

On Fri, 1 Jun 2001, Phill Jenkins wrote:

> 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 15:30:42 UTC