- From: Matt May <mattmay@adobe.com>
- Date: Tue, 1 Dec 2009 13:23:34 -0800
- To: Ian Hickson <ian@hixie.ch>
- CC: Cynthia Shelly <cyns@microsoft.com>, HTML Accessibility Task Force <public-html-a11y@w3.org>
On Dec 1, 2009, at 2:40 PM, Ian Hickson wrote: > Specifically, I feel two of the requests -- adding summary="" and > orientation="" -- are actually likely to cause harm to accessibility > overall rather than help it. Yes, yes. We've heard this many times before from you. Now, instead of just repeating the same old statement without evidence, how about backing it up? > Re summary="": I think it would be better to encourage authors to always > provide visible text explaining tables, since this would would be more > likely to be correct, and would benefit more users. Except for the cases where the author doesn't want that text to be visible, which will be most of the time, since it's a duplication of the visual structure, as well as being unsightly in many cases. The net result is that you are putting visual presentation at odds with accessibility to non-sighted users. And history shows that visually-impaired users nearly always lose when authors are faced with that dilemma. > We've seen We who? > that when accessibility information is not visible to authors by default, they tend > to screw it up, so having help information only visible to screen readers > is unlikely to help accessibility Almost none of the accessibility features of HTML to date have affected visual presentation. And yes, people do screw them up with some regularity (as they do with many other elements and attributes in HTML). But the former is not the cause of the latter. You haven't convinced me one bit that the only reason accessibility features fail is that they're not presented visually. Based on my experience, I don't think the visual presentation is even a factor. It's an issue of: 1) Inadequate user education, which extends beyond the spec itself into all of the educational materials that are derived from it. 2) Poor authoring practices, including (older) tools that generate non-conforming code. In your spidering experiment, we saw one tool generate a large proportion of the bogus summaries. In any case, @summary won't go away. It's ingrained in the authors, the tools and the policies surrounding the web. The solution isn't to ignore all of this and do something different and incompatible with today's web content and tools, and making users with disabilities wait years longer for their authors and tools to catch up. The cowpaths are already worn in here. > and we've seen that for the few authors > who do provide helpful summary="" text tend to put values in that > attribute that would be useful to more than just users of accessibility > tools, causing other users to miss out on potentially useful information. So issue guidance on how UAs may use @summary, and save us all another few years of this debate resurfacing every couple months. - m
Received on Tuesday, 1 December 2009 21:24:07 UTC