- From: Jukka Korpela <jukka.korpela@tieke.fi>
- Date: Wed, 31 Jul 2002 09:35:04 +0300
- To: "WAI (E-mail)" <w3c-wai-ig@w3.org>
RUST Randal wrote: > I have a form that is formatted by a table. Two of the three > columns have INPUT elements that need to be associated with LABEL > elements. The only thing I could think of was to add the LABEL > inside of the TH tag. I'm afraid I don't quite understand the intended structure. Is your example intended to have really just _one_ row? In that case, I wouldn't use a table like that, with column headers; rather, I'd put each field and the associated label on one row, or just on one _line_ (without using a table at all). But if the example is intended to contain more rows, as I'll presume in the sequel, then the <th> elements in <thead> cannot contain labels. A <label> element must be associated with a single field of a form, not a a set of fields. On the other hand, those <th> elements need not contain labels; they are just column headers. The headers can (and should) be associated with rows or columns using table-related markup, such as scope="...", as you have done, and this has nothing to do with forms. On the practical side, few user agents can make use of table accessibility features at present, so it is best to design tables so that they work even without the structural information like associations of cells with row and column headers. At least the cells should, if possible, contain hints about their role, such as units associated with numbers; "42 km" or "$42" is better than plain "42". Along the same lines, it is best to avoid putting a naked form field into a cell, relying on the association between a column header being actually presented to the user. Thus, for example, I would put something like <td><label for="exceptionCode"><abbr title="Exception">Exc.</abbr></label> <select id="exceptionCode"> <option value="0" selected>None</option> <option value="1">Code 1</option> <option value="2">Code 2</option> </select></td> (For reasons to include the first <option> there, see http://www.cs.tut.fi/~jkorpela/forms/choices.html ) The second column of your table contains a set of radio buttons. There are several problems involved, like the question about the default selection, but labels aren't really the problem: you have labels there. However, you have labels _before_ the radio buttons. While this is natural in principle, conforming to the recommendable practice for text fields, it does not correspond to the common style on the Web, or in forms on paper. Sometimes we need to accept established practice, even if it is poor theoretically, since deviating from it would cause confusion. I think it should be said explicitly in the WAI recommendations or other guidelines that for radio buttons and checkboxes, the label should appear after the control, since this is what people are accustomed to (and user agents should be able to deal with that). Currently http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-labels doesn't say anything about this, even implicitly in an example. But the HTML 4.01 specification uses that style in examples: http://www.w3.org/TR/html4/interact/forms.html#h-17.4.2 (Somewhat oddly, it does not use <label> for radio buttons even in the section where it discusses how to enhance forms using <label>.) So what about your first column, the name? It's now plain text, not a form field, so a label problem does not arise. But if it is to be replaced by an input field (with or without a default value), then what? In principle, there should be a label with text like "Name", even if the field is in a column with a good column header and all that. In practice, it might not result in a catastrophe not to use a label, especially if you add a title="..." attribute that might help some users. -- Jukka Korpela, senior adviser TIEKE Finnish Information Society Development Centre http://www.tieke.fi Phone: +358 9 4763 0397 Fax: +358 9 4763 0399
Received on Wednesday, 31 July 2002 02:31:57 UTC