W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > April to June 2001

Re: Table Questions

From: Liz Roberts <liz@netlogix.net>
Date: Fri, 11 May 2001 16:48:59 -0400
To: "Charles F. Munat" <chas@munat.com>, <w3c-wai-ig@w3.org>
Message-ID: <B721C87B.14AF8%liz@netlogix.net>
> re: http://www.geocities.com/lizdesign/tables.html
> Steven McCaffrey wrote:
> "The only minor difficulty is to figure out which comes under property and
> which under description but I think all the important information is clear."

> That he could misinterpret this table so is a superb example of just how
> difficult it can be to construct tables that make sense when read aloud by
> screen readers without actually hearing them read aloud. As a visual user, I
> would never have guessed that someone could misinterpret Property
> Description. But after seeing the output of Steven's screen reader, I can
> easily see how one might, especially in the context of a discussion of
> tables.

Could this perhaps be a result of expecting poorly formatted tables?

> I would have to say that you *are* using the table for layout. Yes, there is
> a logical relationship between the data, but then there usually is a logical
> relationship between the items on a page. What you are really building here
> is more of a list. If you want to structure it in tabular format, a better
> way would be to use fields and records (like a database table):
> Property         Type    Level   Bedrooms
> 123 Main Street  Duplex  Ground  5
> 456 Elm Street   Duplex  Ground  3

This is actually almost identical to the page of results that comes before
the detail page I used in my example.  While not totally nonsensical, it
seems ironic that one record doesn't get a table, while more than one does
(perhaps that only seems hard to comprehend to me).

> (Some might object to this use of DL, but I think it's appropriate.)

I think this is key:  was hoping there was greater consensus.

> Thus, I conclude that your use of an HTML table is not so much to organize
> the data into fields and records, as to format your list into two columns. I
> think that this is the source of your feeling that you are really doing
> layout. (Another hint is your use of colons after Address, Type, Level,
> etc.)

I would assert the use of colons is simply a formatting choice; at times I
use them, at times not.  But I do get your point, and I do agree it seems to
be a layout table.  But I'm not convinced that the HTML attributes defined
in the spec would be inaccurately (note that I did not use inappropriately!)
used if included to further define the relationships of data within this

> But the most important question here is, Does it work? And with the
> exception of Steven's misinterpretation of Property Description (pretty
> harmless), it seems to. My complaint would be not with the use of a table
> per se, but with the overall aesthetic. The "properties" and their
> associated values are equally weighted. To my eye, that makes the table
> difficult to read (easier, in fact, to hear read aloud). Using the list
> format above, particularly the one with the definition list, would result in
> a more readable output while using a structure that better represents the
> key=value pair nature of the data.

Just so you know, I use CSS to format the whole thing.  I just took out all
the style attributes and such so that the code would be uncluttered and the
table code itself clearer to tear apart.

Received on Friday, 11 May 2001 16:52:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:12 UTC