- From: Ian Hickson <ian@hixie.ch>
- Date: Sat, 5 Dec 2009 21:52:42 +0000 (UTC)
- To: Laura Carlson <laura.lee.carlson@gmail.com>
- Cc: HTML Accessibility Task Force <public-html-a11y@w3.org>
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