RE: Table Techniques - Summary

I will concur and want to thank Michael for his full testing and
description.  It was most helpful.

Permit but do not require null summary attributes for layout tables.

My only hope is that this does not make designers lazy and they ignore
the data table summary as required.

Sincerely,
Lee Roberts
President/CEO
Rose Rock Design, Inc.
(405) 321-6372
http://www.roserockdesign.com


-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of John M Slatin
Sent: Monday, August 18, 2003 11:42 AM
To: Michael Cooper; WAI GL (E-mail)
Subject: RE: Table Techniques - Summary



I agree: permit but do not require null summary attribute for layout
tables.

John Slatin, Ph.D.
Director, Institute for Technology & Learning
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.ital.utexas.edu
 


-----Original Message-----
From: Michael Cooper [mailto:michaelc@watchfire.com] 
Sent: Monday, August 18, 2003 10:57 am
To: WAI GL (E-mail)
Subject: 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 16:17:36 UTC