Re: labels for form controls that don't have labels.

* data in the table.  i.e. the checkbox is the leftmost cell on the row,
* but the row consists of data that comes under the column headings such
* as date, phone number, time, cost, etc.  Also other examples may be a

I'd suggest that an appropriate table heading would meet the spirit, if
not the letter, of the requirement.

* set of radio buttons, one per row.  One solution is to put label element
* tags around the whole row and use appropriate for and id attributes.

This is not a solution, because it creates an HTML syntax violation.
The only things that can appear before <TR> are <TABLE>, <THEAD>, <TBODY>,
</COL>, </COLGROUP> and </TR>.

> 2.  A series of edit fields designed to take parts of a phone number.
* I.e. country code, area code and number are separate, but the only
* on-screen label is the one for the entire set.  One solution is to use
* invisible text labels (see below).

Why is it obvious what the fields are, but not so obvious that the user
can type the whole as one entry?  Entering as one field would be faster for
most people.

> 3.  a series of form controls in different cells of the same row of
* a table where the table is a data table, but certain values need to
* be altered or set on submitting the form.  One solution is to code the

I don't understand this one.  Forms should work without any client side
auto-updates.

> 1.  use visibility: hidden or display: none; for a span that covers the
* contents of the label , thus allowing a descriptive label to be included
* but not appearing on the screen.  Some z-index and positioning styles

The basic objection here is that you are denying the label to non-audio 
users.  display: none applies to all media types, but, in any case, the
most often cited assistive technology behaves as though it were 
a visual browser, not like an audio one.

> 3.  Including label, but only to surround the form control itself, but
* not to include any real other label element content.  Rather, include
* title attributes on both the label and input element as required.

This is no different than simply using title attributes, and therefore
purely token conformance to the label requirement.

Incidentally, this was quite difficult to read because you have put the
whole of each paragraph on a single line.  Lack of newlines in text/plain
email means that there are no line breaks, not that the user agent should
guess the language and apply appropriate ones.  Most GUI email programs
are broken, although the latest Mozilla email program can be configured
to behave correctly; the user agent autors should have used MIME rich
text if they wanted the receiving user agent to reflow the text.

Received on Wednesday, 28 May 2003 02:54:08 UTC