I'm a stickler for semantics when I code a site, but the more I think about properly coding input forms with semantic markup, the more I think that it's actually semantically correct to use tables to structure a form.

Sound like anathema? Maybe so. But I'm certainly not the first to suggest that tables are actually suited for the task.

Here's my take: As long as you aren't using attributes in the table to manage the layout (remember our friend CSS?), I think table rows, headers, data cells and captions are all worthy of marking up a form. And more important than being worthy, I will argue that tables are essential for form layout, especially with backwards-compatibility in mind. Because while you can lay out a form with CSS and avoid tables completely, your layout may not necessarily degrade gracefully in older clients. However, with tables, forms still maintain a structure that allows them to make sense, with or without CSS.

Here's the issue: The relationship between a piece of data and it's label doesn't have to be visual, but when you have two or more pieces of related data (or potentially hundreds, thousands, etc.), representing the relationships that exist between different items in the same group of data is absolutely essential to interpreting the meaning of said data.

A table indicates the very essence of those relationships, and it just happens to do that in a very visual manner, the same way a carraige return indicates a new paragraph, which is a visual clue that a new thought is on the way. In the case of HTML, the <p> tags make this distinction, which I ironically forgot to include in the first version of this post.

Anyway, think about the last form you filled out. If you entered your name, address and credit card number, you were giving away what will essentially become tabular data. Your vitals become part of a table when it enters the database, and then likely again when it's displayed in a customer record.

So isn't this data tabular before it enters the database as well?

If that's the case, it stands to reason that a <label> element belongs in a <th> cell, and the ensuing input element would be placed in a <td> cell.

So now the question becomes, is placing a <label> inside of a <th> cell redundant? I'd say no, because of the added functionality that a <label> element, properly marked up with a for="" attribute provides. With a matching for="" attribute, most browsers allow you to activate the labeled element by clicking on the text of the label. Of course, you could duplicate this functionality with some DOM scripting, but that seems like a lot of work just to avoid one extra element in your code.

Can you layout a form without a table? Absolutely. But is it semantically incorrect to use a table to structure your form? I don't think so.

Labels: accessibility, semantic-code, tables, XHTML

Reknowned CSS guru Tantek Çelik gave an rock-solid presentation on "Meaninigful XHTML" at Web Essentials '05. I wasn't there, but he's posted the deck to his blog, so you can relive the presentation in the comfort of your own monitor like I just did. That's swell.

And now after reading his presentation, I need to go back into my templates and change how I deliver links to other people's blogs. I guess I never really thought of linking to a blog as a citation, but that's essentially what your doing. Ah, semantics. Gotta love 'em.

Labels: semantic-code, XHTML

A staple of website layout since the mid 90s, the <table> tag gets a bad name these days in Web Standards circles, because it was never intended to be used to build layouts. Tables are meant for -- surprise! -- organizing tabular data, whether you want to publish Danny Ainge's career statistics or mutual fund returns. Sadly, 90% of the tables on the Internet are being used for layout in a day and age when they're just no longer necessary.

When it comes to tables and Web Standards, there's more to know besides "don't use them for layout." Specifically, not enough webmasters know that there are simple ways to make their tabular data instantly more accessible and understandable to users of alternative browsers. Make a habit of implementing these lesser-known attributes and powerful secondary tags to make your tables accessible. Check out the sample code below:

   
<table summary="This table lists all of the vehicles 
impounded by the Hazzard County Sherriff's Department.">
<caption>Impounded Cars - Hazzard County Sherriff's Department</caption>
<thead>
 <tr>
      <th scope="col" abbr="Make">AUTOMOBILE MAKE</th>
         <th scope="col" abbr="Model">AUTOMOBILE MODEL</th>
         <th scope="col" abbr="Year">Yr.</th>
         <th scope="col" abbr="Color">COLOR/DESCRIPTION</th>
 </tr>
</thead>
<tbody>
 <tr>
      <td>Dodge</td>
         <td>Charger</td>
         <td>1969</td>
         <td>Orange</td>
 </tr>
</tbody>
</table>   
    
   

Code breakdown:

• summary="" attribute - The summary attribute should be listed last in the opening table tag, and it's used to give a user a description of the content of the table. The summary isn't intended to be displayed by traditional browsers, but it will be read aloud by screen readers when they enter the table. Also, remember to add a period to the end of your table summary; this will cause most screen readers to pause briefly before beginning to read the content of the table.
• <caption> tag - If you want to display a brief description of your information to visual clients, the little used <caption> tag offers a semantic solution rather than just printing regular text or headers with your table. The caption tag should immediately follow the opening <table> tag, but can be displayed before or after the table with some CSS magic.
• <th> tag - Always mark table headers with the semantic <th> tag. By default, most browsers will center and bold content placed in a <th> cell, but remember, CSS is your friend. And keep in mind that the <th> tag should only be used to denote an actual table heading. Using <th> simply to provide bold and centered style to a table cell is semantically incorrect, and your colleagues will giggle at you behind your back. Not good times. Apply a class to a standard <td> instead.
• scope="" attribute - No longer reserved for oral hygiene, scope will make your breath fresh and your tables more accessible. By adding a scope attribute to a <th>, you provide context to the table header. The two basic attribute values are "col" (column) and "row", and these values specify whether your header cell relates to data that runs down a column or across a row.
• abbr="" attribute - "abbr" is an abbreviation for -- get this -- "abbreviation". Use it to either abbreviate a long table header name, or conversly, to explain an abbreviated table header name.
• <thead>, <tbody> and <tfoot> - These three seldom used tags are optional, but they will help you clearly define the structure of your table mark-up, and they're also considered good form. And as an added bonus, you can use them to isolate specifc cells and groups with CSS.

As with all tips, and especially when it comes to dealing with screen readers, your mileage will vary with these techniques, as the onus lies upon screen reader software to properly interpret your markup. While JAWS 6 seems to be pretty reliable, the prohibitive cost of screen reader software may mean that your users are browsing your content with outdated programs.

These are just the basics to keep in mind, but these tactics will instantly make your tables more accessible. For further information about making tables acceessible, see the W3C's HTML specification.

Labels: accessibility, semantic-code, tables, web-standards