The recent decision about longdesc made me revisit the table-summary proposal [1] again. 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. The argument misquotes Sec 508 guidance doc of 2001. The guidance doc recommends: use caption BECAUSE summary is not adequately supported by AT. This was in 2001. 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. You say, “We are therefore in good company in recommending these techniques”. I say you have picked very very poor examples and you do not even realize it. It appears the intent is to argue just for the heck of it. 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? Or does it highlight the fact there are authors who do not know / understand HTML? 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. 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? 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. It is meant to be written out only where needed in a manner that helps VI users navigate and understand the table. It is wasted on sighted users. Your argument sounds like: “Why should only blind individuals have the opportunity to use white canes? Everyone should go around with white canes”. Disabling / getting rid of a feature that is AT and browser supported is not a good idea. The summary is like a cane and there is no reason to give up either. Often developers end up misapplying accessibility techniques. When techniques are incorrectly used or applied in situations where they are not required, they create more accessibility problems. I have been auditing Web content for accessibility for a decade and advising on how problems can be resolved and have seen this happen many times. I have suggested to WCAG-WG they should include a general ‘failure technique’ to this effect. Although they recognize it, they say a general technique like that is not testable. 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 * 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.
* 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. * 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 * 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! Sailesh Panchang Tel 571-344-1765 Centreville VA * [1] http://lists.w3.org/Archives/Public/public-html/2010Jul/0052.html
