W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2002

RE: Table Headers and Labels

From: Jukka Korpela <jukka.korpela@tieke.fi>
Date: Wed, 31 Jul 2002 09:35:04 +0300
Message-ID: <621574AE86FAD3118D1D0000E22138A95BDDA3@TIEKE1>
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

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>

(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
doesn't say anything about this, even implicitly in an example. But the HTML
4.01 specification uses that style in examples:
(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
Phone: +358 9 4763 0397 Fax: +358 9 4763 0399 
Received on Wednesday, 31 July 2002 02:31:57 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:36:10 UTC