W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2002

[html+css techniques] RE: layout tables

From: Al Gilman <asgilman@iamdigex.net>
Date: Fri, 08 Nov 2002 11:35:43 -0500
Message-Id: <>
To: <w3c-wai-gl@w3.org>
Cc: Jukka Korpela <jukka.korpela@tieke.fi>

Editors of the HTML+CSS techniques:

Kerstin Goldsmith's question and Jukka Korpela's answer provide a good review
of this sticky issue.


Yes, there is a vehicle of sorts via the techniques documents.

There is also a vehicle for errata to the guidelines, but I expect the first
[second, and third] reaction of the WCAG working group would be to treat 
this as a
technique and hence not handled by the guidelines errata process.


-- quote 
from  http://lists.w3.org/Archives/Public/w3c-wai-ig/2002OctDec/0346.html

Kerstin Goldsmith wrote:

 > Has anyone come up with a way to standardize on signaling that a table
 > is being used for layout purposes only?

This is very good question. It has been discussed to some extent, with no
apparent consensus, and different practices exist, and different guides and
programs give different recommendations. So the situation really calls for
some clear statement. I wonder if there's any mechanism for W3C WAI to take
an official position, to give an official interpretation of the Guidelines.

The Guidelines say (checkpoint 5.5): "Provide summaries for tables.
[Priority 3]  For example, in HTML, use the "summary" attribute of the TABLE
element." Note that it does not say "for all tables". However, the related
HTML techniques document describes, at
the summary attribute in a manner that suggests that it's intended to be
used for all tables. But no example is given about a summary for a layout

 > When we run our documentation through our accessibility checking
 > utility, we have told folks to add a null SUMMARY attribute to their
 > tables, and our checking utility recognizes this as a signal that
 > the table need not be checked for association between headers and
 > cells, or for header markup itself.

This sounds trickish, though I see the practical point.

 > It seems that the SUMMARY=""
 > makes sense in the same way that null ALT attributes work for
 > decorative graphics, no?

That's a natural way of looking at it, but maybe not quite correct. For an
IMG element, the ALT attribute by definition gives the textual alternative
to be used in place of the image, when the image is not displayed. Thus,
alt="" says that the adequate textual replacement for the image (when the
image is not shown) is an empty string. And this is of course quite correct
for a purely decorative graphic (unless the graphic itself is being
discussed, of course). For a TABLE element, the SUMMARY attribute is defined
(according to HTML specifications) as follows: "This attribute provides a
summary of the table's purpose and structure for user agents rendering to
non-visual media such as speech and Braille."

The definition is a bit one-sided, since such a summary could be useful even
when the table is presented visually. The user might have cognitive
difficulties in just seeing the structure, or the canvas might be too narrow
for the table without (horizontal) scrolling, so that it's difficult to get
a good picture of it as a whole. So it's useful if a graphic browser gives
the user an optional access to the summary (as Mozilla does: right click on
the table and select Properties).

On the other hand, it's _double_ sided: the summary is supposed to describe
the purpose _and_ structure. The examples in W3C documents add a third job
to that: describing the overall _content_ of the table, like "This table
charts the number of cups of coffee consumed by each senator - -", but this
probably means basically that "purpose" is meant to be read as a content
description, rather than telling the real purpose, i.e. _why_ a table
presents some statistics about senators' coffee consumption. I feel a bit
like a harmonizing exegetic, but I think this interpretation more or less
resolves the doublesidedness:

A summary is supposed to describe the structure of a table, in a manner that
covers the meanings of columns and rows, thereby giving an idea of the
overall content en passant.

Literally taken, this discussion means that summary="" would say that the
table has no structure and, moreover, that it has no purpose (if we take the
word "purpose" in the specification literally) or that it has no content
(since an empty overview of a content is adequate only if there is no

However, one might read "table" as relating not the the table element, with
all its content, but to the pure structure itself. Even then, summary=""
would be problematic.

It is tempting to say that the lack of a summary attribute should indicate
that table is for layout only. But since the great majority of tables on Web
page currently has no summary attribute, such a criterion would lead to
definitively wrong conclusions.

What I suggest is this (and I might be simplifying the situation):
1. For a table used for positioning elements on screen, e.g. so that there
is some material on the left and some other material on the right, use a
summary attribute that explains the contents of the cells. In a way, treat
it as a structural table. Example: summary="First cell: navigation links.
Second cell: content proper." If there are cells with no content, used just
to create borders between content cells for example, I think you should
state this explicitly, like "Fourth cell: no content."
2. For a single-cell table used for formatting purposes such as setting a
fixed width for text or to create a border around it, use a summary
attribute that describes the content of the cell. Example: summary="Copy
text. (This is the only cell in the table.)"

One of the points here is to be prepared to software that processes tables
in an "unconventional" but logical way, giving the user access to each cell
separately, in some suitable manner.

Jukka Korpela, senior adviser
TIEKE Finnish Information Society Development Centre
Diffuse Business Guide to Web Accessibility and Design for All:
Received on Friday, 8 November 2002 12:02:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:33:42 UTC