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

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.
>
>> And the methodology used to determine that the attribute supposedly 
>> isn't being used, is primarily anecdotal, and not particularly 
>> comprehensive. Either it's based on Ian's queries in Google's index, 
>> which can't be validated because there is no non-Google party access 
>> to the raw data used in the queries, or it's based on one movie 
>> interviewing one person.
>
> Philip's data seemed to show similar results independently.
>
But with a much smaller sampling of data.
>> Philip's data has shown that there is a direct (observed, not 
>> statistically measured) correlation between incorrect use of the 
>> summary attribute, and incorrect use of the table element. Frankly, I 
>> would have to assume the same can be said of Ian's own results.
>
> More interesting than that correlation is the apparent absence of 
> summaries that look like the kind of summaries put forward as examples 
> of what authors should be putting in there as best practice. Even if a 
> layout table detection heuristic prunes out some of the bad summaries, 
> where are the good summaries?
>

One might as well ask: where are the good tables? I found it just as 
difficult to find tables being used properly, as summary attribute being 
used properly. For instance, there are several summaries that have a 
value like pid24615. But if you look at the table element, in my 
opinion, it's also not being used correctly. Example:

http://www.nanlingbbs.com/viewthread.php?tid=6899


Oh, and by the way, that link is nsfw. Or is that, <nsfw>?


>> 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. Again, 
referencing my earlier argument, how many good uses of TABLE can you 
find in the list?

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.

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.

Shelley

Received on Monday, 8 June 2009 13:42:11 UTC