Re: CHANGE PROPOSAL: Table Summary

On Sat, 5 Dec 2009, Laura Carlson wrote:
> 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]?

Ben Millard collected convincing data showing that tables existed that 
benefitted from the headers="" attribute, and that assistive technologies 
could not derive the same information from the existing markup. There was 
also evidence showing that headers="" misuse was relatively easily 
algorithmically detectable, such that it didn't harm users. Finally, the 
feature doesn't cause harm to non-AT users.

Nobody has collected equivalent data showing summary="" is useful at 
improving accessibility in practice, and people _have_ collected data 
showing that it is harmful to both AT and non-AT users (in different 
ways).


> They are both accessibility accommodations. What is the difference in 
> applying the principle in the two cases?

The principle is that accessibility accommodations (meaning features that 
authors have no motivation to use _other_ than improving the experience of 
AT users) should be a last resort, to be used when there is evidence that 
their use would improve matters, that their design is likely to lead to 
acceptably frequent good usage, that there are no better solutions, and 
that their introduction would not lead to a reduction in the experience 
for either AT or non-AT users.

Evidence was collected showing that the conditions apply for headers="".
Evidence was collected showing that the conditions did not apply for 
summary="".

That's the only difference.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Saturday, 5 December 2009 21:53:12 UTC