Re: Table Techniques - Summary

I agree too

----- Original Message ----- 
From: "John M Slatin" <john_slatin@austin.utexas.edu>
To: "Michael Cooper" <michaelc@watchfire.com>; "WAI GL (E-mail)"
<w3c-wai-gl@w3.org>
Sent: Monday, August 18, 2003 6:41 PM
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 13:02:39 UTC