- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Tue, 9 Jun 2009 11:52:00 +0300
- To: Shelley Powers <shelleyp@burningbird.net>
- Cc: "public-html@w3.org WG" <public-html@w3.org>
On Jun 8, 2009, at 17:53, Shelley Powers wrote: > Henri Sivonen wrote: >> Indeed, summary="" as a sign of a layout table seems useful >> assuming that it is better supported by existing software than >> role=presentation, but I wouldn't count summary='' as an example of >> the attribute being used to give a longer-than-caption summary of a >> data table. >> > I'm sorry, I'm not sure what your argument is here. I'm observing that in the light of 'best practice' how @summary is supposed to be used, only the empty summary attributes comply but actual longer-than-caption summaries of data tables are nowhere to be found in Philip's data. (summary="Calendar" may be useful but doesn't match the best practice put forward.) >> Which raises the question: If @summary is almost always used on >> layout tables instead of data tables, is it solving the problem >> that it is supposed to solve: providing a summary for complex data >> tables? > > Henri, your argument's logic is flawed. The majority of table usage > is for table layout, so it's not surprising that the majority of > summary usage is on tables being used for layout. Your logic states: > > Most HTML tables are being used for layout. > A certain percentage of HTML tables have an associated summary. We shouldn't assume that layout tables and data tables use summary as often. If summary were used correctly, we should expect all non-empty summaries to be on data tables! > Therefore, summary isn't solving the problem it is supposed to > solve, which is provide a summary for complex data tables. > > Non sequitur My point is this: If @summary were used the way it is said it should be used, we should find a lot of summaries of like "Rows contain destinations, traveling dates, and grand total. Columns contain expense category and total. The first column contains merged table cells." and virtually no summaries like "layout table". Yet, the data shows virtually *no* summaries of the best practice kind. It's not that there's a mass of incorrect use in the data. It's that there's *no* best practice-conforming use to be found at all. (Well, maybe there is if you sift through the data harder.) Even if we accept that @summary has a non-zero success, it sure seems to have an enormous waste rate (people toiling away adding pointless summaries to be discarded by JAWS). >> Obviously, tables are used "incorrectly" so often that it makes >> more sense to develop ways to deal with the incorrect use on the >> client side (detect layout tables and linearize them for AT use or >> for small-screen mobile use) than to try to "educate" the whole >> world not to use layout tables. I don't conclude that the solution >> to use of tables for layout is education. >> > > What does this have to do with @summary? I agree, disregard the > table components when parsing a layout table. I thought you brought up the incorrect use of tables to draw a parallel with the need to educate. If that's not what you meant, please disregard that paragraph. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Tuesday, 9 June 2009 08:52:41 UTC