- From: Roberto Scano - IWA/HWG <rscano@iwa-italy.org>
- Date: Mon, 18 Aug 2003 19:02:29 +0200
- To: "John M Slatin" <john_slatin@austin.utexas.edu>, "Michael Cooper" <michaelc@watchfire.com>, "WAI GL \(E-mail\)" <w3c-wai-gl@w3.org>
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