- From: Al Gilman <asgilman@iamdigex.net>
- Date: Wed, 04 Jun 2003 10:17:36 -0400
- 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: > >http://www.thunders.ca/tabletest1.html >http://www.thunders.ca/tabletest2.html > >These tables layout text but make use of a header (table1) and caption >(table 2). > >Would you describe them as layout or data tables? No. AFAIK The distinction is useful for heuristic purposes, but not for writing guidelines. 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. References: [history] HTML4/CSS2 Accessibility Recommendations http://www.w3.org/WAI/PF/report.html#TABLE [recommended, despite the fact that I haven't read it:] [capsule summary of Yeliz Yesilada's Master's Thesis work] (long URL) http://cascade.man.ac.uk/cgi-bin/index.pl?cmd=resources&action=show&display=item&cat=document&group=aug&item=319&back=http://augmented.man.ac.uk/documents.shtml&next=http://augmented.man.ac.uk/documents.shtml&template=1/ssisti/supporting/rtemplate.shtml&orderby=title Al >Chris
Received on Wednesday, 4 June 2003 10:17:50 UTC