Re: CHANGE PROPOSAL: Table Summary

On Dec 1, 2009, at 5:44 PM, Ian Hickson wrote:
>>> 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's not what I said. By "visual structure," I'm talking about describing the traits of the table that are communicated visually.

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

You're redefining @summary as <caption>. We already have <caption>. And in the real world, it is woefully underused for data tables, despite its relatively limited effect on visual design.

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

Aesthetics and data are hard to reconcile with one another. That doesn't mean that the current approach in HTML5 wins because it's already in the document.

What concerns me is not my sense of aesthetics, nor those who are concerned with accessibility, but rather those who are not. 

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

I'm not saying that. I'm saying that a replacement that defaults to visible will not be used, specifically because it's presented visually.

>> And history shows that visually-impaired users nearly always lose when 
>> authors are faced with that dilemma.
> 
> Could you back this up?

While I presume none of us have documented each instance where we as developers sat across the table from designers who ignored accessibility issues in favor of visual fidelity, those of us who have fulfilled that role will tell you that it's extremely common. It's rare, in fact, that many accessibility issues are _not_ jettisoned in favor of visual fidelity. It'd be folly to draw up a spreadsheet to that effect, but it is no less a fact.

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

You're talking about semantic elements, which are all well and good for accessibility, but not germane to the topic at hand. I'm talking about features specific to accessibility, of which there are few in HTML4 (@alt, @summary, @longdesc, @axis, @scope, @headers), and even fewer in HTML5, thanks to the ongoing battle against hidden data.

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

Wait. If we taught people to write good @summary values, then they'd write _bad_ summary values?

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

I don't see evidence to back this up. I see tools that don't show any signs that they care about validity, which means nothing you do is going to change their behavior, either. I see (thankfully, less and less often) automated evaluation tools that tell authors: add @summary because I said so. But that's not HTML's problem, either. It strikes me that you're attempting to solve a problem that's not yours to solve, by constraining the few who care about the spec to use an element that's less suited to the task at hand.

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

That'll go cheerfully ignored. I see no way people are going to even think to add a paragraph when they're not prompted. At least @summary appears just about everywhere table markup is discussed. Anything detached from that markup stands about a .00001% chance of being used successfully.

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

I've looked at all of the studies you've cited. Apparently I misremembered one of them as your work.

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

Your experience as a spec writer and developer is not the same as my experience as a designer and accessibility specialist. That's the problem with data: it's still analyzed by humans, who remain frustratingly analog. We've looked at the same data on several occasions, and while you've seen no value in what's produced, I've seen a great deal that will likely be lost.

The difference I see is that by putting @summary back in, you won't likely be impacted all that much. By leaving it out, people involved in accessibility work are going to be missing one of the critical tools for table accessibility. And if your proposed solution for this were sufficient, people wouldn't still be raising a fuss.

This is where the data-über-alles train goes off the rails.

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

Guidance _to the UA_. That hasn't been tried before. Seems if you're concerned with the availability of a piece of content to the user, and there's loads of it already out there on the web, you'd light a fire under the browsers, not boil the ocean.

-
m

Received on Wednesday, 2 December 2009 01:02:59 UTC