W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > July to September 2004

Re: HTML Table Markup

From: Phill Jenkins <pjenkins@us.ibm.com>
Date: Mon, 13 Sep 2004 00:35:43 -0500
To: Chris Ridpath <chris.ridpath@utoronto.ca>
Cc: w3c-wai-ig@w3.org
Message-ID: <OF678C8D19.5EB79C38-ON86256F0E.001B3916-86256F0E.001EBCB2@us.ibm.com>
> There's been a lot of discussion lately on the IG list regarding HTML 
> markup.


> Phil Jenkins started a thread on using a null summary to indicate the 
> difference between layout and data tables[1].
> Bruce Bailey started a thread on using the TH element in data tables[2].
> Both of these issues, among others, have been discussed at length on the 
> list and in phone conferences and have led to a series of techniques and 
> for the accessible markup of tables.
> The consensus reached was that TH elements would be used to determine 
> type. Data tables must use TH elements. Layout tables cannot use TH 
> The use of summary on layout tables is still under discussion[3] but the 

> current view is that summary is optional on both layout and data tables.

I introduced null summary to indicate a layout table.  And I agree (and no 
one has disagreed either) that TH elements are prohibited from layout 
tables.  The concern I introduced with ONLY using TH to identify data 
tables is that no automated code checker can tell the difference between 
data tables that are correctly marked up and those that should have TH's 
added - hence the need for a method to positively identify layout tables. 

The only argument I've seen so far is that authors and tools could 
incorrectly add the null summary to a table when if fact it is a data 
table that should have a summary.  The example of tools incorrectly adding 
null alt text was cited - to which my reply is that we can't prevent 
author or tools from being stupid.  Which raises the question, what 
happens when a table has a null summary, but also has TH's?  Is it a bad 
summary or incorrect TH elements?  I submit that this case should be an 
undetermined exception and leave it to the author to approve as valid or 
change it.  Again, I'm trying to improve the automated ability to test 
tables.  I'm not suggesting that all tables must have the summary 
attribute.  Only that those tables that authors choose to positively 
identify as layout tables to be correctly identified with the null 
summary.  Data tables could still have TH elements without a summary 
attribute (not a null summary) and be considered valid.

In other words, how can I tell an automated checked that this is in fact a 
layout table?  By just leaving the TH's out of the mark-up I haven't told 
the checker anything new yet.  The checker will still think that the table 
may need some data table markup added. 

I don't think it is possible for WCAG to change the HTML or XHTML specs, 
but WCAG can, and should, define the correct interpretation for 
accessibility considerations.  For example:
1.  presence of TH elements should be correctly interpreted as a data 
table [not the same as all data tables must have TH elements].
2.  presence of null summary is valid HTML and should be interpreted as a 
layout table.
3.  presence of both null summary and TH elements is undefined (may be 
flagged each time to query the author).
4.  presence of TH and summary="some text" is valid and should be 
interpreted as a compliant data table.
5.  presence of TH and no summary is still valid HTML.

Phill Jenkins
IBM Worldwide Accessibility Center

[1] http://lists.w3.org/Archives/Public/w3c-wai-ig/2004JulSep/0464.html
[2] http://lists.w3.org/Archives/Public/w3c-wai-ig/2004JulSep/0568.html
Received on Monday, 13 September 2004 05:36:20 UTC

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