Re: CHANGE PROPOSAL: Table Summary

On Tue, 1 Dec 2009, Matt May wrote:
> 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.

Do you mean media-specific presentation as one would do in CSS? Or do you 
mean the structure as described in HTML markup?


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

I'm not trying to redefine summary="" at all.


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

I didn't say it did.


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

In that case, you also disagree with the change proposal -- unless I 
misunderstood what Cynthia was saying, the change proposal recommends that 
summary="" be made visible:

| I agree that hidden text is often wrong, or allowed to get out of date. 
| The recommendation that summary SHOULD be rendered visibly in authoring 
| scenarios is intended to help mitigate this issue.
 -- http://lists.w3.org/Archives/Public/public-html-a11y/2009Dec/0009.html

Incidentally, the HTML5 spec already includes examples for how to mark up 
table explanations that are not shown by default. A media-specific 
attribute is not required for this.


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

I do not think it is reasonable to claim that something is a fact without 
backing it up, based solely on anecdotal evidence, while at the same time 
demanding that I back up my own statements with data. Our standards of 
argumentation should be the same. Either we need to back up our opinions 
with data, or we don't. If we do need data, then opinions that aren't 
backed up should not be considered. If we don't, then it isn't reasonable 
to respond to my own opinions with comments like "yes, yes" and "how about 
backing it up".


> >> 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 don't understand. All the features I listed _are_ specific to 
accessibility. If you mean features that have no side-effects on any users 
outside of those with assistive technologies, then naturally such features 
are rare, since they are symptomatic of a harmful design anti-pattern -- 
accessibility is architecture, you can't do a good job bolting it on as an 
afterthought. This is especially true on the Web, here authors are largely 
oblivious to the special needs of small parts of their audience, and thus 
we have to make sure that their products are as accessible as possible 
without being able to rely on their abilities to do anything explicitly 
accessibility-specific.


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

Beats me. They do, though; see the data collected in the e-mail I cited in 
response to your demand for data.


> > 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 was basing this on your own statements:

| Based on my experience [...] It's an issue of [...] (older) tools that 
| generate non-conforming code. In your spidering experiment, we saw one 
| tool generate a large proportion of the bogus summaries.
 -- http://lists.w3.org/Archives/Public/public-html-a11y/2009Dec/0003.html

Was your statement not based on evidence?

You work for one of the Web's largest WYSIWYG authoring tool developers, 
so if I'm wrong about the above, could you describe what the state of the 
art in WYSIWYG tools regarding making table accessible is, and how it is 
conducive to good summary="" attribute values? Personally, I've never seen 
anything better than just a text field, which in my experience (I can't 
back this up) encourages the user to create suboptimal values in the name 
of Accessibility, which is consistent with your experience of authoring 
tools leading to poor accessibility.


> 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 absolutely is our problem. Saying it's not our problem is akin to 
saying that usability problems in aircraft controls are not a problem if 
they lead to accidents -- that pilots or pilot trainers are to blame for 
those accidents. While it's true that the direct blame for poor 
accessibility of a Web site is primarily on the site's author, we _do_ 
share the responsibility in that our decisions in designing the language 
have a huge impact on how often those authors will make those mistakes.

By including summary="" -- at least assuming it isn't changed to be 
visible -- we are encouraging authors to make a mistake that we could 
avoid by instead persuing a line of education that leads to a greater 
chance of the descriptions being accurate and useful.


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

I'm not sure what you mean. What problem isn't ours to solve?


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

Can you back up that number?

This line of reasoning can easily be tested -- we can look for techniques 
of writing accessible pages that don't have dedicated markup, and see how 
often they are used relative to techniques that do use dedicated markup. 
"Skip navigation" links would be an example of a technique that has no 
dedicated markup (it just uses the regular link markup). How often is that 
used relative to, say, longdesc=""? If your hypothesis is correct, there 
would be far more pages using longdesc="" than pages with skip navigation 
links. Are there?


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

If you had looked at all the studies I cited, why did you say I was not 
providing evidence?


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

Indeed. Our experience is irrelevant, though; we should use data.


> The difference I see is that by putting @summary back in, you won't 
> likely be impacted all that much.

I really don't care how much _I_ am impacted. I am not the audience having 
trouble with tables.


> By leaving it out, people involved in accessibility work are going to be 
> missing one of the critical tools for table accessibility.

Can you back this up?


> And if your proposed solution for this were sufficient, people wouldn't 
> still be raising a fuss.

Does the opposite also apply? That is, would people not complain if 
summary="" was sufficient?


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

If you don't think that evidence is relevant, why did you ask me to 
provide it?


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

What guidance do you think would help? Even if we don't include summary="" 
in the language allowed by authors, we should definitely include guidance 
for user agents. What would you suggest?


On Tue, 1 Dec 2009, John Foliot wrote:
> Ian Hickson wrote:
> > 
> > To clarify, you are arguing that explaining complicated information to 
> > users who have trouble understanding complicated information will lead 
> > to them understanding the information _less_ than if that information 
> > was not explained to them?
> 
> What I am saying is that the textual content that would go into the 
> @summary value is *generally* seen as content targeted towards a 
> specific user group - those that cannot see the complex associations 
> inside of a complicated table, as they cannot process that information 
> as a whole: screen readers must process the content inside of tables in 
> a predominantly linear fashion.
>
> However, users with cognitive difficulties comprehend better when the 
> information being presented to them is clear, simple and unencumbered by 
> a lot of supporting 'distraction'.

It seems pretty clear that all users would benefit from information being 
presented in a clear and simple way without distractions. I don't think 
anyone is arguing against that. The point is that even once this has been 
done, if the table is still not intuitive (to users of screen readers, 
users with cognitive difficulties, users who have simply never seen the 
table before, or anyone else), then the explanatory text will be useful to 
more than just users of assistive technologies.

I disagree strongly with your implied assertion that explanatory text for 
tables consists of clutter. However, even if it was, the spec does 
currently recommend at least one mechanism by which the explanation can 
be hidden by default.


> Developers might also want to consider the following suggestions made by 
> Singh, Gedeon, and Rho (1998). They suggest that designers should:
> 
>     * _Remove the need for reading_ and writing skills in web exploration
> through graphic representations and point and click interfaces.

We're talking about tables that are so complicated they need explanatory 
text. I highly doubt that by that point removing an extra paragraph (of 
explanatory text!) is going to make things any better.


> One need not look any further than Google's home page to see this 
> 'simplicity works' design perspective - why else would the Google 
> designers *not* have an in-the-clear label for the search field?

A tooltip is not a table's explanatory text. I think this is a 
non-sequitur.


> It comes down to two perspectives: Universal Design versus Accommodation 
> features.  In a perfect world, Universal Design would solve all 
> problems, as the Design would be, well, Universal.  However, when 
> Universal Design fails is there another way forward?  The answer is via 
> Accommodation features.  @summary is one such Accommodation feature - it 
> exists when other 'solutions' are either not viable or wanted, for 
> whatever reason. Matt May and Cynthia Shelly are two senior developers 
> who have specifically noted in the context of *this thread* that they 
> have experienced, first hand, the tug and pull of Accessibility 
> Requirements versus other Business and Aesthetic considerations, and 
> they, like I, have experienced more than once the defeat of 
> Accessibility enhancements (or even basic needs) to the Trump Card of 
> other voices at the decision table. Having solutions such as @summary in 
> the developer's toolbox provides an additional option when options are 
> required - it allows for a compromise solution that you have not offered 
> in any other way.

I'm not arguing with the principle; I'm arguing with this application of 
the principle.


On Thu, 3 Dec 2009, Leif Halvard Silli wrote:
>
> Thus I agree that aria-sort="" is basically very similar to what I 
> suggested. Using aria-sort="" as a way of informing about the 
> orientation thus seems possible. Only possible thing: What if it is not 
> clear what kind of order, but it is still clear which column?

I recommend addressing ARIA feedback to the working group working on ARIA.

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