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

On Jun 8, 2009, at 16:41, Shelley Powers wrote:

> Henri Sivonen wrote:
>> On Jun 8, 2009, at 15:11, Shelley Powers wrote:
>>
>>> Henri, your reasoning is a little flawed here.
>>>
>>> A statement has been made that the attribute isn't being used, but  
>>> then you're saying that authors are expending effort on the  
>>> attribute, which is the same as saying, it is being used. Which is  
>>> it? Is it being used, or not?
>>
>> If authors put *something* in the attribute but either AT  
>> heuristics suppress the attribute or users disregard the attribute,  
>> it is being used but is not useful.
>
> The majority of uses of summary are blank, appropriately so, because  
> the majority (all, from what I've found so far) of uses where the  
> summary is blank are in tables used for layout. It's difficult to  
> define either usefulness or lack of same in this scenario. But the  
> fact that AT heuristics disregard the attribute in these cases would  
> seem to be useful, if we judge usefulness based on doing what they  
> should properly be doing.

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.

>>> Then the argument is given that those who want to keep the summary  
>>> attribute have to perform research far beyond anything being done  
>>> with any other aspect of HTML5,
>>
>> Well, personally, I'd have been convinced by something like asking  
>> a few screen reader users to find out if they found table summaries  
>> to be a net benefit. I guess I'll have to trust the 3 opinions  
>> Steve relayed, although I still don't comprehend where the useful  
>> summaries are found when the data I can check (Philip's data) shows  
>> a mountain of bad summaries--not a mixed mountain where the bad  
>> could be pruned automatically out leaving a pile of good ones.  
>> (Unless, of course, a summary such as "Calendar" counts as a good  
>> summary despite not being the kind of summary that a summary is  
>> supposed to be per best-practice examples.)
>>
> Calendar with links is useful and is also in the list.

My point is that summary="Calendar" doesn't seem to conform to how  
summary is supposed to be used properly. (It's a short caption rather  
than a long summary of contents.)

> Again, referencing my earlier argument, how many good uses of TABLE  
> can you find in the list?

Very, very, few other than the blog sidebar calendars. (I found two  
before giving up.)

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?

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.

> Seems that we have a lot of education to do across the board. That's  
> where providing good examples and descriptions in the HTML5  
> specification (and associated primer) would go a long way to ensure  
> proper use of @summary. We also need to work on educating developers  
> for the more popular content management systems, such as Drupal and  
> Wordpress, in how to incorporate @summary and CAPTION properly when  
> creating modules or plug-ins that generate HTML content. Not to  
> mention authoring tools, like Dreamweaver.

Why hasn't all this already happened given that @summary has been in  
HTML 4 for a decade? How long is it going to take?

> As an aside to this discussion, not specifically addressing anything  
> you wrote Henri, one other argument that has been put forth is that  
> the text needs to be visible, in order to ensure that the field is  
> used correctly. That one makes me a little uncomfortable. When I  
> read this argument, it seems, to me, to have an underlying  
> philosophy that a field designed specifically for those who can't  
> see is not inherently useful. That may not be the intent of the  
> argument, but I have a feeling an argument like this will end up  
> biting the W3C in the butt.

No, that's not the argument. The argument is that if the sighted  
maintainer of the page reviews only 'visible' parts of the page, the  
'invisible' parts get out of sync when the page is maintained.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Monday, 8 June 2009 14:19:02 UTC