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

Re: [#248] Data and layout tables: identifying and marking

From: Al Gilman <asgilman@iamdigex.net>
Date: Wed, 04 Jun 2003 10:17:36 -0400
Message-Id: <>
To: "Chris Ridpath" <chris.ridpath@utoronto.ca>, "WAI WCAG List" <w3c-wai-gl@w3.org>

At 09:51 AM 2003-06-04, Chris Ridpath wrote:

>Here are links to 2 example tables that may muddy the destinction between
>layout and data tables:
>These tables layout text but make use of a header (table1) and caption
>(table 2).
>Would you describe them as layout or data tables?


AFAIK The distinction is useful for heuristic purposes, but not for writing

Most tables have a layout function.

Tables have data-structure-revealing function in varying degrees, not well
captured by one yes/no question.

One needs to do scene analysis to capture into the markup the data
relationships that are conveyed by the layout.  This applies to all scene
designs, not just those hung on a table backdrop as a layout grid.  So
whether the table grid is one to one with the graphically indicated
relationships, or there is a more complex relationship between the
significant relationships and the table-element-constructed layout grid, it
is the significant relationships that we need to capture.

There is no binary line at which something becomes a data table and not a
layout table.

Tables have data-structuring function at all levels.  You could call this
zero to 100% but there are different aspects.  How regular is the structure
that is being conveyed?  How significant are the relationships?  Are there
inline metadata in the form of [de-facto or as-marked] header cells?
Headers, at least de-facto headers, are common in layout tables, where there
are often internal headers for a layout region set off as separate table cells.

The key fact in the relationship between the graphical and rhetorical
structures of a web page table is that alignment in the graphical structure
is used to convey relatedness between parts of the content, and that the
relatedness is under-explained (in ways other than layout) as a result.

The way to approach the markup requirements for tables is not to try to make
a binary choice "is this a layout table or a data table?" but rather to
dig deeper and ask "what does the layout in this table tell the visual user
about the relationships among parts of the scene?"  Break the visual scene
down into parts, their types and relationships, and then you will have the
agenda that the overt text plus the markup has to address.


  HTML4/CSS2 Accessibility Recommendations

[recommended, despite the fact that I haven't read it:]

[capsule summary of Yeliz Yesilada's Master's Thesis work] (long URL)



Received on Wednesday, 4 June 2003 10:17:50 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 21:07:30 UTC