W3C home > Mailing lists > Public > www-archive@w3.org > November 2010

Re: About table summary- the proposal of 07/2007

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 16 Nov 2010 02:50:20 +0000 (UTC)
To: Sailesh Panchang <spanchang02@yahoo.com>
cc: www-archive@w3.org
Message-ID: <Pine.LNX.4.64.1011160238000.26618@ps20323.dreamhostps.com>

(-whatwg for the same reason as the previous e-mail)

On Thu, 12 Aug 2010, Sailesh Panchang wrote:
> The examples of summary not being useful or summaries that duplicate 
> stuff already on the page demonstrate that authors do not know how to 
> write good summaries or determine when a summary is needed.

Indeed. It seems likely that we can improve this by encouraging authors to 
write explanatory text that is useful for _everyone_, not just AT users.

> Quoting a JAWS user who says he has summary disabled in the settings 
> only illustrates a user who does not know the features of his AT and not 
> the usefulness / futility of the summary attribute.

Actually the user in question is quite an advanced user and it seems 
highly likely that he would be more knowledgable than most. That _he_ 
found the feature useless speaks volumes.

> Well today in 2010 I can show countless pages with badly coded tables: 
> data tables without TH and layout tables with TH and summary and THEAD. 
> So does that mean the elements like TABLE, TH, THEAD should be banned? 

Yes. They are, in fact. Using <table> for layout, for instance, is in fact 
*less* conforming than using summary="", according to the HTML spec today.

> The problem is most developers / authors do not know what AT is, how AT 
> works, how a blind guy navigates a table, what non-visual access is, 
> what audio user interface is. So obviously you cannot expect them to 
> write imaginative and helpful summaries.

As I said for longdesc="": The goal is to make the Web better. Who cares 
if it's our fault for designing a bad language or the author's fault for 
nott using it correctly -- we should still fix the language to make it 
more likely that authors will do the right thing, which is to make their 
pages more accessible.

By changing the message from "write a summary attribute with an 
explanation of your table's structure" to just "write an explanation of 
your table's structure", we move authors from thinking of this as an issue 
to be dealt with later to them thinking about this as they write the 
tables in the first place. It is no longer a checkbox to fill in after the 
site is done (or maybe never); it becomes part of how you write tables, 
something to consider when making the page's style sheet, etc.

> Think of the more simple alt attribute for a moment. And you get all 
> kinds of rot being written up as the alt-value simply because authors do 
> not understand / care / or are writing it simply to pass a check by an 
> automated tool. So do you suggest getting rid of all text equivalents 
> because there are no good ones you can find?

I can count on the fingers of one hand the examples of summary="" I've 
seen that are actually useful (despite looking at literally millions, 
either with automated tools or directly by examining the source). The 
alt="" attribute is used correctly vastly more often.

> You say: “Furthermore, the summary="" attribute is intended only for 
> non-sighted users, which runs contrary to our design principles of 
> universal access. Hiding information from sighted users even when the 
> information would be useful to them is not good design”.
> No one is asking authors to hide content that is meant for all users. On 
> the contrary the summary is a means of giving extra help to VI users.

If you give extra help only to some users, you are by definition hiding it 
from other users.

> It is wasted on sighted users. 

No, it's not. If your table is complex enough that an AT user can benefit 
from an explanation, I guarantee that other users can too.

Furthermore, if you encourage author to write explanations for *all* 
users, you are more likely to have *any* explanations that help visually 
impaired users at all than you are if you ask authors to only write 
explanations for visually impaired users.

> Your argument sounds like: “Why should only blind individuals have the 
> opportunity to use white canes? Everyone should go around with white 
> canes”.

Everyone *does* have the opportunity to use white canes.

> The conclusions drawn too are baseless, without evidence and 
> ill-conceived bordering on the hilarious:
> * have tables complicated enough that non-visual users need a 
> description
> Counter: Financial / statistical tables get very complex. See census 
> data or labor statistics or health / epidemiology data

And I, as a sighted user, would like an explanation of those tables, just 
like a visually-impaired user would.

>  * are able to write a description
> Counter: As stated above, authors / developers cannot write imaginative 
> / helpful summaries without understanding how blind users use assistive 
> technology and navigate tables.

If they can't write a good summary, then it doesn't matter *what* features 
we provide for them to put their summaries in.

>  * are not willing to expose this description to all users
> Counter: The content meant to be exposed via a summary may be of no 
> significance to sighted users. Authors always have the ability to 
> display whatever content they choose to.

This is incorrect, IMHO. In all the examples we studied of summary="" 
values, all of the summaries that would be useful to AT users would also 
have been useful to non-AT users.

>  * are not willing to use CSS techniques or <details> to hide the 
> information from the default visual presentation
> Counter: The value of the summary attribute is “content” and not 
> merely presentational that it can be left to CSS

You misunderstand this bullet point.

>  * will remember to update the attribute when the table changes.
> Counter: That is certainly an accessibility issue that one sees all the 
> time.e.g.  state of a UI element is not correctly reflected via text or 
> alt is not updated when image-replacement technique is used by a script. 
> Maybe they should ban UI elements or JavaScripts entirely!

Or maybe we should just have the text visible to all users, including the 
(sighted) author, so that the author will notice when the text is wrong.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 16 November 2010 02:50:49 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:33:54 UTC