- From: John Foliot <jfoliot@stanford.edu>
- Date: Tue, 1 Dec 2009 15:02:41 -0800 (PST)
- To: "'Matt May'" <mattmay@adobe.com>, "'Ian Hickson'" <ian@hixie.ch>
- Cc: "'Cynthia Shelly'" <cyns@microsoft.com>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>
Matt May wrote: > > 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? I have to side with Matt here - Ian's statement of fact is not based on any publicly available data; he simply says that we must trust him on it. Sorry, no can do. Ian is entitled to his *opinion* here, but the specification cannot hinge on only one man's opinion. As a corollary to Ian's statement however, having the value of what would normally be considered the @summary content visible 'in the clear' on pages with complex tables might also cause harm to some users - specifically those with cognitive impairments - as you then are dealing with an overload of information which could leave some users confused or unsure of the data they are consuming. Thus the argument for placing this information in the clear is as fraught with potential harm as not doing so. Has anyone on the HTML5 Accessibility Task Force outside of Ian seen any evidence of @summary causing *harm* to users? > > > Re summary="": I think it would be better to encourage authors to > always > > provide visible text explaining tables, since this 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. This truism exists for a number of contentious accessibility features within HTML 5: @summary and @longdesc being two that spring instantly to mind. > 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. ... and I might add finding examples of *this* problem is like shooting fish in a barrel. Everyone gets that some members of the authoring group don't like Meta-data, and their reasoning for this dislike is not unsound. However, given the choice between Meta-data and no data, Meta-data is the hands-down winner every time. As well, no one is insisting that @summary be a mandatory attribute of the table element, but it deserves to be a fully vested and supported attribute that serves an identified need in a way that no other suggestion to date does. > > > We've seen > > We who? In this case, I have, on numerous occasions across the years, asked Ian for a list of *any* accessibility specialist or advocate with whom he has previously consulted, and have never received a reply. Thus I can come to no other personal conclusion then that the 'we' in question is named Ian Hickson (in the singular). > > > 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 Question: why cannot the browsers expose, on demand, the value of the @summary attribute natively? Why must @summary be thought of as simply for screen readers? The browser vendors are a creative lot, can't they come up with a solution along the lines of 'right-clicking' on a table and having the @summary value exposed in the UI? > > 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. > > So issue guidance on how UAs may use @summary, and save us all another > few years of this debate resurfacing every couple months. +1 to Matt. JF
Received on Tuesday, 1 December 2009 23:03:20 UTC