Re: CHANGE PROPOSAL: Table Summary

Hi Ian and John,

John Foliot wrote:

>> It comes down to two perspectives: Universal Design versus Accommodation
>> features.  In a perfect world, Universal Design would solve all
>> problems, as the Design would be, well, Universal.  However, when
>> Universal Design fails is there another way forward?  The answer is via
>> Accommodation features.  @summary is one such Accommodation feature - it
>> exists when other 'solutions' are either not viable or wanted, for
>> whatever reason. Matt May and Cynthia Shelly are two senior developers
>> who have specifically noted in the context of *this thread* that they
>> have experienced, first hand, the tug and pull of Accessibility
>> Requirements versus other Business and Aesthetic considerations, and
>> they, like I, have experienced more than once the defeat of
>> Accessibility enhancements (or even basic needs) to the Trump Card of
>> other voices at the decision table. Having solutions such as @summary in
>> the developer's toolbox provides an additional option when options are
>> required - it allows for a compromise solution that you have not offered
>> in any other way.

Ian Hickson wrote:

> I'm not arguing with the principle; I'm arguing with this
> application of the principle.

If I recall correctly, Ian didn't you argue the same against restoring
the table headers attribute for a year and a half and yet ended up
restoring @headers in the spec making it conforming?

If that is correct from your perspective, what is the difference
between the @headers issue [1] and the @summary issue [2]? They are
both accessibility accommodations. What is the difference in applying
the principle in the two cases?

Thanks.

Best Regards,
Laura

[1] http://esw.w3.org/topic/HTML/IssueTableHeaders
[2] http://esw.w3.org/topic/HTML/SummaryForTABLE

Laura L. Carlson