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

Henri Sivonen wrote:
> 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.)
>

I don't believe a requirement for summary is that it must be longer than 
caption. Your argument is looking for a fault where there is none.


>>> 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!
>

And we would expect there be no layout tables, either. The web is 
imperfect.

>> 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).
>

You keep using one metric, an arbitrary count, as your measurement of 
success, Henri. And I keep repeating that, especially when it comes to 
issues of accessibility, that counts and empirical observations are not 
the most effective determinant of what counts as success.

Sometimes a measurement of success is for those who need such features 
to be assured that they are not forgotten; nor that those who would 
create a new generation of web pages discount their challenges by 
removing the few features created specifically for them.

How people perceive the actions of the HTML WG become just as much a 
metric for success when it comes to meeting needs and demands for 
accessibility.

Regardless, I will repeat: the sole purpose behind removing @summary 
seems to be that it will be "harmful". No one has provided a case for 
the harmfulness of this attribute. And the group responsible for 
ensuring web accessibility has not only stated that they disagree with 
the claim of harmfulness, they have made a specific request to have it 
re-instated. According to the charter governing the HTML WG, the course 
is clear.



>>> 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.
>
I don't care what you all do about layout tables, though I noticed the 
discussion in the #whatwg about including algorithms for tool makers to 
follow when dealing with non-data tables. Of course, such is outside of 
the scope of the charter for this group, but that's neither here nor there.

To return to the only point that matters: the reason we're given why 
@summary was removed is that a claim was made that it was "harmful". 
There is no proof of the harmfulness of the attribute. Unless there is 
another reason to remove this accessibility markup, I then remind the 
group of its charter commitment to cooperate with other groups, 
including the W3C WAI Protocols & Formats.

Again, my usual disclaimer: I am not an accessibility expert, not part 
of any group, giving my own opinion as a web professional, and so on.

Shelley

Received on Tuesday, 9 June 2009 11:32:01 UTC