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

An interesting article at Digital Web Magazine looks at why your clients won't pay for accessibility. Christian Heilmann raises some important points, and it's definitely worth a look-see.

My takeaway? Web firms may need to rethink how they sell accessibility testing (if they're even doing it in the first place). Because while clients may pay lip service to Section 508 and buzzwords like it, when it comes time to trim the perceived fat, accessibility testing will likley be the first thing lopped off.

Labels: accessibility

Access Matters recently confirmed what I knew was true of JAWS but was guessing about others: the leading screen readers speak your pages in the order in which they are coded and ignore CSS positioning. Good news for us; reordering your content with CSS is not only a best practice for search engine optimization, but also screen reader accessibility. So when you're dropping that two column layout with left navigation, put your content in the first <div> and your navbar in the second.

Another consideration would be the positioning of buttons in forms. If you want to position an action button above a table of data (or any other content), you could potentially code it after the table and use CSS-P to place it where you like.

Armed with this knowledge, we can now recommend another best practice: if you can't test your site in an actual screen reader, reading your xhtml in order for content comprehension is a good low-fidelity test to see if your content will make sense. Use Firefox's Web Developer extension to view your page without CSS or go into your code and do it manually.

I did a lot of testing recently with a screen reader for a client that was talking about screen reader accessibility, but balked when we explained that coding to Section 508 and WCAG doesn't guarantee anything and that we'd need to add a screen reader testing phase to declare their site "screen reader accessible."

Along the way, I learned quite a bit about JAWS 6, and realized that the learning curve for a sighted user is pretty significant, so I can imagine the hurdles facing blind users. I had to do quite a bit of Googling to find out that JAWS offers a "tables mode" and a "forms mode" that allows it interpret things like scope attributes on <th> tags, or to successfully select more than one item in a combo box.

It's been said several times elsewhere, but screen readers still have a way to go in standards support and just overall usability. In the meantime, the onus is on us to discover how to best accomodate users of assistive technology.

Labels: accessibility, CSS

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