Is it semantically correct to have a HTML Form set out in a Table?

Question

We all know that it is wrong to use a Table as a layout aid.

I often use tables to structure forms. Is this semantically correct?

I am wondering about this as it is logical for a form to be in a table layout (at least the forms that I create), as all the fields have labels that correspond to the expected input into the fields. The data obtained is then definitely semantically correct displayed in a table. But is it the same for the form?
I have a feeling that it is a matter of opinion, but I am interested to hear people's reasoning behind their opinions.

Answer 1

============

EDIT : Thanks @Will Martin. Actually, I checked, it would seem that using table to structure form IS semantically correct as it is displayed on w3c standards document. See here : http://www.w3.org/TR/html401/interact/forms.html#h-17.9.1

============

I've read an article (unfortunately in french) yesterday that was basically saying that you shouldn't use table to structure forms. (http://www.alsacreations.com/article/lire/1209-display-inline-block.html)

It doesn't say why not but it says that you should use the display:inline-block. Be carefull though, display:inline-block is a great parameter but it has drawbacks when browsing IE7-6 (not surprisingly).

Read this article (in english) that explains 'inline-block' => http://robertnyman.com/2010/02/24/css-display-inline-block-why-it-rocks-and-why-it-sucks/

Answer 2

The web standards project has made a full tutorial on the why and how to avoid tables in html forms. It's a very easy read and answers all your questions:

http://www.webstandards.org/learn/tutorials/accessible-forms/

Answer 3

It's not just a matter of opinions - there are both semantic and practical problems with using tables with forms.

Generally speaking, simple forms that consists mostly of label - input pairs, such as login forms seen on websites today should not need any additional markup, since label and interactive form elements would be all you need in terms of semantics. Any additional markup would be added baggage, adding unnecessary weight to your page - CSS should be flexible to do almost anything you want, and fieldsets can be used for additional separation of the different sections of the form.

But even when you have a form that's obviously a table, you should still consider other methods first - there are accessibility issues with with mixing tables and forms, as indicated in this article on 24 Ways. The same article also shows how you might instead adapt fieldsets to do the same job, and definitely makes for an interesting read.

Answer 4

This sounds more in the vein of "debate" than Q & A. However, I've always felt that any form layout that demands a table structure (with the sole exception of data grids/spreadsheets, which are by definition tables) is a poorly thought-out user experience. Collections of checkboxes, labeled inputs, etc. can all be arranged more flexibly (and semantically) without using tables.

Answer 5

It depends on the form, I think. Some forms may make sense as a table -- for example, one where you have a series of key-value pairs:

<table>
<tr>
    <th scope="row"><label for="first-name">First Name:</label></th>
    <td><input type="text" name="first_name" id="first-name" /></td>
</tr>
<tr>
    <th scope="row"><label for="last-name">Last Name:</label></th>
    <td><input type="text" name="last_name" id="last-name" /></td>
</tr>
<tr>
    <th scope="row"><label for="color">Favorite Color:</label></th>
    <td><input type="text" name="color" id="color" /></td>
</tr>
</table>

The combination of LABEL elements using FOR attributes that correspond to the ID of the associated INPUT means that screen readers will be able to read the form sensibly. I've added TH elements to indicate the semantic relationship within the table between the LABEL cells and the INPUT cells.

However, doing it that way would not be my first choice. The presence of the table markup will make it more laborious to listen to using a screen reader, due to the announcement of each table row/cell. Some of the semantic information from the table (the association of TH header with TDs in the row) actually duplicates the semantic link between the LABEL and the INPUT, so that with a screen reader you may wind up listening twice to the same information about how these things are related.

Instead, I would do something like this:

<style type="text/css">
label { display: block; text-align: right; }
label input { width: 100px; }
</style>

<label for="first-name">First Name: <input type="text" name="first_name" id="first-name" /></label>

<label for="last-name">Last Name: <input type="text" name="last_name" id="last-name" /></label>

<label for="color">Favorite Color: <input type="text" name="color" id="color" /></label>

That would give you much the same effect with less HTML. It has the labels associated with their inputs both explicitly (using FOR/ID) and implicitly (because the INPUTs are child elements of the LABELs). It does mean that you have to be able to anticipate how wide your inputs have to be, and there's a ragged left edge due to all the text being right-aligned.

There's also the problem of adding in checkboxes and radio buttons. In their case, it makes sense to have the input first and the label after it; but that doesn't look very good with the example I've given.

So, basically? Formatting forms is a pain in the butt. Although they often consist of name-value pairs that would make logical sense as a table, there are potential accessibility issues with that approach. I would strongly prefer to avoid tables-based solutions for a problem like this, unless you have a compelling reason for using tables.