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

Re: Layout versus data tables proposal for null summary attribute

From: Richard Schwerdtfeger <schwer@us.ibm.com>
Date: Thu, 26 Aug 2004 13:30:42 -0500
To: Phill Jenkins <pjenkins@us.ibm.com>
Cc: "Michael Cooper" <michaelc@watchfire.com>, w3c-wai-ig@w3.org, Wendy Chisholm <wendy@w3.org>
Message-ID: <OFE7C29E6A.5D6BFD15-ON86256EFC.006598AF-86256EFC.0065B142@us.ibm.com>

We are already addressing this with Role in the DHTML roadmap. We should
avoid the one offs.

Rich Schwerdtfeger
STSM, Software Group Accessibility Strategist/Master Inventor
Emerging Internet Technologies
Chair, IBM Accessibility Architecture Review  Board
schwer@us.ibm.com, Phone: 512-838-4593,T/L: 678-4593

"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.",

             M                                                          To 
                                       w3c-wai-ig@w3.org, "Michael Cooper" 
             08/26/2004 12:43          <michaelc@watchfire.com>, Wendy     
             PM                        Chisholm <wendy@w3.org>             
                                       Layout versus data tables proposal  
                                       for null summary attribute          

Dear Interest Group member, please send your comments directly to me or the

Please do not include a discussion about whether to use CSS verses tables
for layout.  We already agree that CSS is the preferred solution.  Whether
we use CSS or tables for layout is not the disability issue, what really
matters is that the reading order is logical when linearized.  For example
when CSS is off or not available, or when using a magnifier or screen
reader software to navigate the content in a logical order.


For devices and user agents that do not support CSS layout and for older
pages still using tables for layout, the proposal is to recommend a best
practice for distinguishing between data tables and layout tables by
including the summary attribute, but leaving the contents empty (null).

Simple Example:

<table title="layout table for navigation" summary="">
<tr><td>more content</td></tr>

Layout tables are those tables in HTML that do NOT have row and/or column
headings (TH's), do NOT have Captions, and do NOT have other mark-up
associated with tabular data for which the table markup was originally

Data tables are those tables in HTML that do or should have row and/or
column headings (TH's), do or should have captions, and do or should have
other markup, such as summary, scope, and other attributes and elements
associated with tabular data.

Other proposals included using the title attribute to include the keyword
"layout".  The disadvantages to this proposal include having the tool tip
show up on each and every layout table in graphical browsers, the title
being spoken, depending on settings, when using screen reading software,
and if we proposed using the null title="", then we wouldn't be able to
provide additional contextual information for which the title attribute is

The proposal to use the null summary="" attribute has the following
1. The null summary="" attribute will not be spoken by screen reading
2. The summary attribute can be checked for null by authoring tools as a
convention to indicate the table is for layout.  If we eliminated the
summary attribute completely from the markup, then there is less of a
guarantee that the author made a conscience decision to identify the
articular table as a layout table.
3. If the keyword "layout" were included in the summary attribute, screen
reading software would currently speak the term "layout", the contents of
the attribute,  each time the user navigated to a layout table, which on
many complex designed pages, would be annoying and too verbose for the
user.  It would approach the undesirable experience of reading the source
HTML code.
4. The user agent could be configured to skip or ignore layout tables
identified with the null summary="" attribute when navigating.
5. Authoring tools could be more intelligently configured to test for
reading order in layout tables and correct tabular data markup in data

Acceptance of this proposal would require coordination between WCAG 2.0,
UAAG, ATAG, and assistive technology vendors.  Authors could immediately
implement this best practice without negative side effects.

Please feel free to forward this proposal to others.  If forwarding to a
list serv, please copy me.  I will collect all the comments by the end of
August and reply with an updated proposal to the WAI coordination group.

Thank you,
Phill Jenkins
IBM Research - Accessibility Center

(image/gif attachment: graycol.gif)

(image/gif attachment: ecblank.gif)

Received on Thursday, 26 August 2004 18:31:17 UTC

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