RE: Table Techniques - Summary

I have read all of the messages and followed this issue closely and
would like to add another 'aye' to this solution.

Chris Brainerd

Instructional Designer

Real Choices ACCESS

Center on Disability Studies

University of Hawaii

Chris.brainerd@cds.hawaii.edu

808-956-9356



-----Original Message-----
From: Roberto Scano - IWA/HWG [mailto:rscano@iwa-italy.org] 
Sent: Monday, August 18, 2003 7:02 AM
To: John M Slatin; Michael Cooper; WAI GL (E-mail)
Subject: 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 Friday, 22 August 2003 23:58:40 UTC