RE: CHANGE PROPOSAL: Table Summary

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