Re: CHANGE PROPOSAL: Table Summary

On Tue, 1 Dec 2009, 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've backed this up many times, most comprehensively here:

   http://lists.w3.org/Archives/Public/public-html/2009Jul/0148.html

(Search for "Some have argued" for a discussion of some public data 
sources that show this.)

I am glad that you agree that we should base our task force 
recommendations on data and not opinions, however.


> > 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 value of text in a summary="" attribute should not be a trivial 
description of the table structure. That leads to a poor experience for 
screen reader users (accessibility tools provide dedicated mechanisms for 
determining the table structure).

Text that would be appropriate for explaining tables to screen reader 
users are equally appropriate for users with cognitive difficulties, users 
inexperienced with the subject matter, and users that are in a hurry. Thus 
it should be shown to everyone. I do not agree that this is unsightly. 
(That's a subjective statement though, and we probably shouldn't be basing 
our recommendations for improving HTML's accessibility on our personal 
sense of aesthetics.)


> The net result is that you are putting visual presentation at odds with 
> accessibility to non-sighted users.

If you are saying that there is media-specific content to be shown, then 
CSS and media queries are the more appropriate technology to expose this 
information correctly to different users. However, I don't buy that this 
is the case.


> And history shows that visually-impaired users nearly always lose when 
> authors are faced with that dilemma.

Could you back this up?


> > We've seen
> 
> We who?

The HTML working group.


> > 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.

That is clearly incorrect. Almost all the accesibility features of HTML 
affect visual presentation. <em>, <strong>, <cite>, <h1>, <p>, <ul>, <ol>, 
<var>, <object>, <caption>, <th>, <input type=radio>, <label>... and 
that's just HTML4 features; a huge portion of the new features in HTML5 
are accessibility features and affect visual presentation: <input 
type=date> et al, <ol reversed>, <meter>, <progress>, hidden="", <time>, 
<command>, etc, all affect presentation and are key parts of making HTML 
more suitable for users with special accessibiliy-related needs.


> 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.

You haven't convinced me of the reverse either.


> Based on my experience, I don't think the visual presentation is even a 
> factor.

Based on experience, I think it is.


> 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.

I do not believe that it is realistic to expect us to improve education to 
the point of authors writing good summary="" attribute values. Even if we 
did, the data referenced in the e-mail cited above actually shows that 
even the most educated and motivated authors use summary="" incorrectly.


> 2) Poor authoring practices, including (older) tools that generate 
> non-conforming code.

Tools are an especially strong reason for us not to encourage people to 
use summary="". The state of the art in WYSIWYG tools does not lead to a 
user experience that is conducive to good summary="" attribute values. In 
fact, it leads to the opposite -- it encourages the user or the tool 
writer to create suboptimal values in the name of Accessibility, actually 
worsening (according to your own assertions) the experience.

We would be better off encouraging tools to keep out of this and 
encouraging authors to explain their tables independent of the table 
markup and specifically encouraging them to avoid doing so just as a 
checklist measure, but as a key part of writing up any tabular data.


> In your spidering experiment, we saw one tool generate a large 
> proportion of the bogus summaries.

I don't think I ever did a spidering experiment for summary="". Could you 
elaborate on what you are referring to here? My opinions of summary="" are 
based exclusively on studies done by other people.


> In any case, @summary won't go away.

summary="" won't go away only because it isn't anywhere to start with. 
Virtually nobody uses it, and the vast majority of the few people who do 
use it use it incorrectly.


> It's ingrained in the authors, the tools and the policies surrounding 
> the web.

Could you back this up? This runs directly counter to my own experience 
and to the data I've seen.


> 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.

I'm not suggesting ignoring all of this, I'm suggesting learning from it.

I'm not suggesting doing something incompatible with today's web content 
and tools, I'm suggesting using the humble <p> element which works in more 
places today than summary="" does.


> The cowpaths are already worn in here.

I agree. I just don't think summary="" is a cowpath, I think the data (as 
shown in the e-mail cited above) shows that summary="" is off in the 
weeds, far from any path.


> > 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.

Guidance has not succeeded in the past; why do you think it will succeed 
in the future?

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

Received on Tuesday, 1 December 2009 23:44:54 UTC