It's common knowledge these days that you shouldn't use tables for layout, right? In New Zealand we are often required to comply with the NZ E-Government Web Guidelines. Section 11.2 states,

Do not use tables for layout, use style sheets instead.

So that's pretty clear right? Using tables to layout the controls of a form must be a bad thing. Well maybe.

The primary reason for this standard is accessibility. There is certainly widespread use tables to control the layout of unrelated data elements and nasty examples of muliple nested tables that can cause the smartest screen-reader to put their arms up in dispair. This is clearly not best practise and I think we all know this.

However, a lot of people have taken this standard to mean that you should only use tables for, well, tables. You know, a matrix of numbers or other related data with headings. So if you want to control the layout of your form labels and entry controls you're left with CSS. The downside to this is,

CSS sucks at controlling form layout

OK, so let me just back up this wild statement. I can hear all the Elegantus-Coderectus's sharpening their knives and gnashing their teeth. Check out this aricle on how to use the fieldset element combined with CSS to control layout.

  • The style sheet contains 145 lines of code
  • The fieldset elements within the HTML page total
    • 54 lines
    • 1674 characters (excluding spaces)

In comparison the table approach takes.

  • No style sheet
  • The table element within the HTML contains
    • 49 lines
    • 638 characters (excluding spaces)

Yikes, purely based on lines of code the CSS approach is about 400% more verbose.

Added to this, consider the effort required to,

  • Change the layout to use 4 columns not 2
  • Change the layout to allow some input controls span multiple 'columns'
  • Reuse the CSS on another input form which has slightly different requirements
  • The amount of effort and hacks this guys had to do to get this to work for all browsers

Don't get me started on maintainability, robustness, simplicity - the usual arguements for using CSS in the first place! This is a disaster.

Now, some of you will be screaming out about accessibility. Agreed, the article I'm referring to gives a pretty poor example of using a table for form layout. Let's see how we can use a table that is just as accessible as using CSS.

Consider the layout below.

Now check out this markup.

<table id="loginForm" summary="This table is used to enter your details about your feature request.">
    <tr>
        <td>
            <label for="fullName">Name:</label>
        </td>
        <td>
            <input id="fullName" title="Enter your fullname" name="fullname" type="text" accesskey="f" />
        </td>
    </tr>
    <tr>
        <td>
            <label for="email">Email Address:</label>
        </td>
        <td>
            <input id="email" name="email" type="text" accesskey="e" />
        </td>
    </tr>
    <tr>
        <td colspan="2">
            <label for="request">Feature Request:</label>
        </td>
    </tr>
    <tr>
        <td colspan="2">
            <textarea id="request" rows="8" cols="40"></textarea>
        </td>
    </tr>
    <tr>
        <td colspan="2">
            <input id="submitButton" title="Press this button to submit your feature request" value="Submit" type="button" accesskey="s" />
        </td>
    </tr>
</table>

There are a number of things to notes.

  • The use of labels is essential - whether your using tables or CSS this is a no brainer
  • You can make use of the summary attribute of the table element to provide additional information about the intention of the table.
  • The title attribute on the button can also provide information for screen-readers to use
  • Appropriate use of the accesskey attribute
  • You could argue that the contents of this table are related and an appropriate use for a table (unlike using a table to layout header/footer/content areas)
  • You should make use CSS to control other aspects of this table. For example, prefered dimensions of input elements, how labels get rendered, general presentation aspects (colour and fonts)

Further, the NZ e-Government Web Guidelines state,

Do not use table for layout unless the table makes sense when linearised

Linearisation is a process used by screen-readers that 'flattens out' the contents of a screen. You can see the effect of linearisation on a page using the Firefox extension, Web Developer (Miscellaneous -> Linearize Page). When the above table is linearised, we see.

As you can see, everything is still readable and in a logical order. No problem.

So, in my opinion, using tables to layout forms can be done in an accessible and compliant manner. It's also significantly quicker and more maintainable than equivalent CSS approaches (I still can't believe people use this same arguement to defend CSS). Of course there will be situations where tables are abused and aren't appropriate but let's not get too religious about it and agree that tables do have a place outside standard data tables.