Re: Summary of Thursday's IRC conversation about @summary

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