RE: Table Techniques - Summary

[Summary of my post about table summaries: we should permit but not require
the null summary on layout tables.]

My perspective is similar to Ben's. Although as an evaluation tool developer
one might expect me to support a requirement for a null summary attribute on
layout tables, I don't. While it is true that, if consistently used, the
null summary could be a useful indicator that we have a layout table,
especially in combination with other features like the absence of table
header elements, I don't believe author uptake of this would be great enough
that I could design a tool to rely on that. It's the same problem we have
had with table headers, especially a few years ago - the tool could not rely
on the presence of table headers to indicate a data table, because it might
be a layout table that is misusing table header markup. Tools still have to
fall back on other means of identifying the kind of table - some kind of
heuristic or asking the user. The presence of a null summary could be useful
to a heuristic but I would not rely on that solely in developing such a
detection mechanism.

So I think we need to consider how human consumers of Web pages, not
automated evaluation tools, use the summary attribute when we determine the
recommendations we will make. I think it's been agreed that the summary can
be very useful, particularly on data tables. It can also be very noisy,
particularly on layout tables, and it is often desirable to omit it, or
leave it null. The question here is, is there a value to providing a null
summary instead of omitting it, as we recommend for alt text of images?

I ran a test of tables with no summary, a null summary, a summary with only
whitespace, and a summary with real content. Then I checked how current
versions of JAWS and WindowsEyes handled them. Both tools treated null
summary identically to missing summary - they simply did not announce a
summary. Only in the case of a non-whitespace summary did they even indicate
a summary attribute was present. I could not find any verbosity options to
change this behavior. I also consider this the appropriate behavior - if the
tools announced the presence of a null summary, they would create noise,
exactly what we're hoping to avoid by suggesting a null summary.

Note that this is different from the case of images and the alt attribute.
With no alt attribute these tools will generally indicate that there is an
image, and often default to something annoying like reading the file name.
With null alt, they gracefully ignore the image, which is the desired
behavior (assuming null alt isn't being abused to shut up a tool, of
course). I also consider this appropriate behavior.

Other people have described a core difference between alt and summary that
I'd like to underscore. The alt attribute provides a text fallback for a
non-text element. The summary attribute provides descriptive information
about structured text, but does not function as a fallback. Therefore the
two attributes need not be treated equivalently in our guidelines.

Based on all this the requirement I would propose is: 

"Do not provide summary content for layout tables. A null summary attribute
is permitted but not required."

This supports the earlier proposal, which does not seem to be under
contention, that layout tables should not have summaries. Permitting a null
summary does not do any harm so there is no need to forbid it, though I
don't really see the value of it. Tool developers would be free to consider
the presence of a null summary as a flag for a layout table, if they want.

Michael

Received on Monday, 18 August 2003 11:56:47 UTC