Re: Subj: Re: retention of summary attribute for TABLE element

Gregory J. Rosmaita wrote:
> james wrote, quote
> I don't actually know the reasons for not including summary but I would 
> guess they were related to the fact that @summary is tying up important 
> metadata in an invisible attribute. Invisible data is more likely to be 
> missing or incorrect than visible data; according to [1] @summary is 
> present on about 2.5% of tables, I would expect it to be unhelpful on 
> many of those (though clearly some actual research would be needed here. 
> [2] has some results, mostly from CMS templates).
> unquote
> 
> GJR: i think the search parameters you used are too limited - summary 
> may or may not be the first attribute for a TABLE, but it usually 
> isn't, so searching for summary=" yields more results

Actually the code search seems to return cases where summary is not the first 
attribute as well. In any case, I was more concerned with the quality of the 
data in @summary than the number of results. Since I use a graphical UA I don't 
have a feel for what/how much information is needed for a summary to be useful, 
so I'm not the best person to evaluate these results (I also think the survey is 
highly biased).

> james also wrote, quote
> OK, this sounds like a use case for a feature providing an overview of a 
> table's contents. In general I think it's better to work from use cases 
> + backward compatibility requirements rather than HTML4 directly. It 
> seems like some of the problems could be solved automatically e.g. 
> saying how many rows and columns are in the table. Is this not the case? 
> If this can be done, the remaining problem sounds like it could be 
> solved either through <caption> or another mechanism for associating 
> text that is, by default, displayed in visual UAs with the table. Of 
> course I also believe that the behavior of @summary should be specced 
> for UAs.
> unquote
> 
> GJR: it's not just a question of raw statistics - my screen-reader tells
> me that it is X columns by Y rows, but that doesn't alert me to the fact 
> that there may be two rows of table headings the first spanning all the 
> TABLE's columns, the other only a select few (tables such as the *** 
> example on andre's test page [note *]; the more nested tables, the worse 
> for the screen-reader user, as one has to traverse and inspect every 
> table between the first table and that nested table for which the user 
> is searching

Is it conceviable that this process could be automated by the screenreader 
scanning the <th> elements and using a combination of their position, their 
scope attribute (if present) and their row/col spans to deduce the number of 
columns and rows?

> as far as the wiki page HTML/SummaryForTABLE, do you want your comments 
> and suggestions slash questions under reasons for deprecation, under 
> work-arounds, or raw data?  in any event, i will add your post to the 
> list of posts on the topic...

Well I think the fact that @summary is explicity invisible metadata is a reason 
to remove it, so that argument should go into that section. I think explicit 
linking of (default) visible text content to a table should be suggested as a 
possible alternative to the summary attribute.

-- 
"Eternity's a terrible thought. I mean, where's it all going to end?"
  -- Tom Stoppard, Rosencrantz and Guildenstern are Dead

Received on Wednesday, 13 June 2007 15:19:03 UTC