[Irl-dean] HTML Question - Forms, labels and table based layouts

[Barry McMullin]

On Fri, 18 Apr 2008, MacIonmhain, Eoin wrote:

> Thanks very much Dónal, Éamon and Josh for your responses to my question,
> they've been very helpful, and you've given me plenty to chew on :)

Just before this thread dies completely, can I just log that -
perhaps contrary to what others have said - I *do* consider that
there are situations in which it is appropriate to structure a
form using a table (i.e., where the table is properly regarded as
a "data table"); and in that specific case, table header markup
*may* reasonably be used as a way of "labelling" form controls,
*instead* of using the label element.  In particular, where what
one is dealing with is, semantically, an array of form controls,
then I think this may be the most appropriate solution.

Just to be clear, I want to claim that doing this, in such
circumstances, would formally conform with WCAG 1.0 checkpoint
12.4:

   "Associate labels explicitly with their controls. [Priority 2]"

OK, I admit that the text of that checkpoint goes on to say:

   "For example, in HTML use LABEL and its 'for' attribute."

but that is only a "for example"; I do not read this as meaning
that use of the label element is the *only* allowable technique
for meeting the checkpoint, even in the context of HTML. (I have
tried to decipher whether the current WCAG 2.0 draft says
anything different about this, but I think it is just equally
equivocal...)

I'm not quite sure whether this applied to Eoin's original case.
But an example of the sort of thing I have in mind might be an
e-commerce site, where one is accessing a "catalog" of products
under some "category".  So the category page might list 20
individual products, all with a product code, a product
description, and a price.  So far this all fits precisely the
definition of a data table.  But additionally we want a form
control for each product allowing a user to enter the number of
items of that product that they wish to add to the shopping
basket.  I think it is perfectly appropriate to put these items
in a further table column, where the column header functions as a
(shared) label for all these controls; even though it is not
using the label element.  But that is precisely the point -
because the label element doesn't support the idea of a single
label being shared by multiple controls. (Of course each control
also potentially has an additional "row header" - perhaps the
product code in this example - also functioning as a lable; so,
in general, a user may need to reference both headers to orient
themselves to the unique function of an individual form control.)

Of course, one would want to give the user a clue that they
should refer to table header information for form control lables
in this context (perhaps in the table summary attribute?).

Some (?) might say that an alternative approach would be to have
a column of links (rather than form controls), where each link
brings one to a dedicated page, with a form for entering just the
desired quantity of that one product.  Clearly that page, dealing
with a single product, would not need a table, and could use the
conventional HTML label element markup for the form controls.
But to my mind this would be significantly less functional (for
all users); and would therefore be an example of inappropriately
applying a "literalist" interpretation of accessibility
guidelines rather than thinking about what is the most correct,
semantic, and functional approach to the particular interaction.
It's the sort of "hack" one might introduce because, for example,
some particular automated accessibility checker *insists* that
the only way of "labelling" form controls in HTML is via the
label element; but would be entirely a case of the tail wagging
the dog.

Now there is still a quite separate *practical* question here;
being, how well would this sort of thing be rendered by currently
deployed assistive technologies.  I am not sure of that, and
would certainly be interested in any reports. In particular, I
believe that JAWS has, historically at least, relied on a "modal"
interface, where it may have been difficult to use "form mode"
concurrently with "table mode". As I say, I don't know if that is
still true, but would be interested in any clarifications.

Nonetheless: while I am a supporter of "practicality" I would be
loath to recommend that anybody make their long-term markup
design decisions based on the arbitrary vagaries of any
particular assistive technology (no matter how widely deployed it
might be...).

Best regards - Barry.

--
Barry McMullin, Dublin City University
   phone: +353-1-700-5432
   web: http://www.eeng.dcu.ie/~mcmullin/