- From: Robert J Burns <rob@robburns.com>
- Date: Wed, 25 Feb 2009 01:47:43 -0500
- To: Ian Hickson <ian@hixie.ch>
- Cc: "Gregory J. Rosmaita" <oedipus@hicom.net>, Leif Halvard Silli <lhs@malform.no>, Maciej Stachowiak <mjs@apple.com>, James Graham <jgraham@opera.com>, Joshue O Connor <joshue.oconnor@cfit.ie>, Steve Axthelm <steveax@pobox.com>, Steven Faulkner <faulkner.steve@gmail.com>, Simon Pieters <simonp@opera.com>, HTMLWG <public-html@w3.org>, wai-xtech@w3.org, wai-liaison@w3.org, janina@rednote.net, Dan Connolly <connolly@w3.org>, Matt Morgan-May <mattmay@adobe.com>, Julian Reschke <julian.reschke@gmx.de>, W3C WAI Protocols & Formats <w3c-wai-pf@w3.org>
Hi Ian, On Feb 23, 2009, at 9:54 PM, Ian Hickson wrote: > Before I jump in to the e-mails themselves, I want to make sure we all > agree on the underlying goals that we are trying to accomplish. > > Problem statement: some users find navigating tables complicated, and > would like a description of the table so that they can make better > use of > the table. Such users might be blind, using an accessibility tool, or > might have cognitive difficulties, or might just be unfamiliar with > the > structure of particularly complicated tables. > > There are several things to consider when evaluating possible > solutions: > > 1. Whether the solution would actually solve the problem if used > right. > > 2. Whether the solution hurts any users, or fails to help users that > should be helped. > > 3. Whether the solution would be used correctly enough for users to > actually pay attention to it. A feature that is rarely used in > practice is better than a feature that is used wrongly, since the > latter will cause users to ignore the feature even when it is used > correctly. > > I think it's clear that summary="" could solve the problem if used > right. > It seems like it would fail to help users that don't get access to it > (like users of visual browsers). You make a logical leap here that has no basis. There is nothing that I can see in the HTML5 draft that requires visual browsers to hide 'summary' attribute values (or any attribute values for that matter) from users. So we cannot conclude that UAs will fail to provide access to other users to the table summaries. In fact authors and users can provide such access through the strategic CSS authoring[1] . Earlier I have suggested adding new norms for interactive UAs to display such information and you argued it was inappropriate for the spec to address such norms[2][3] (despite the fact that the spec already addresses such norms). However, if the spec cannot address such norms than it is also improper to assume UAs will not make such information available. So your repeated arguments that 'summary' is not available for all users is simply incorrect. Making such an argument would be like saying the 'title' element is of no use since it is not displayed by UA. Yes it is often displayed in the title bar, but that is a custom and not a requirement, recommendation or even suggestion of the HTML5 draft. The HTML5 draft does recommend (even though you say it is inappropriate) that UAs "use the document's title when referring to the document in their user interface", but it is still not displayed in the flow of the document by default which appears to be what you're saying about the 'summary' attribute. More importantly, the claim that users are being short-changed because they cannot read content intended for the visually and cognitively impaired seems at best misguided and at worst malicious. I say misguided since table summary information is meant to describe features of a table that may be readily apparent to the visual and cognitively unimpaired users and is therefore redundant (e.g, an earlier example where a table might visually indicate its current sort/ collation state and such information would be redundant to repeat as text). I say malicious since the continued repetition of the fallacious arguments seem directed at ensuring such information is not made available to visually and cognitively disabled users. Table summary information is information that often should not be displayed in the normal flow of a document. Authors should not be required to include the information in the normal flow of a document in order to include it within a document. However, by forcing authors to use caption or paragraphs or other visible by default facilities, means authors may be less inclined to provide table summaries within their documents. Certainly other facilities might be added to HTML to replace the summary attribute. However, using facilities such as the 'details' element again requires the information be exposed in a way that may make authors reluctant to include the information. If the summary information is obvious to a visual user why would an author want to invite the user to click a disclosure button and read through a distracting summary to learn that the information in the 'details' element tells them what the user already knows? However allowing a summary attribute (or in the future a summary element within the caption might be suitable) permits authors to include the crucial information and direct it squarely at the users who need it. Simultaneously, these features allow authors to create the visual experience they prefer and not the visual experience preferred by you as the editor of the HMTL specification. I do not understand how you think this WG would tolerate these types of impositions on the needs of authors and users, defended with the weakest arguments we've yet seen. While the other concerns raised regarding the frequent misuse of summary are certainly valid, such misuse does not suggest the feature is substantially harming users. On the contrary, users can relatively quickly determine whether the summary is of any use or not and move on to table interrogation, to another section of the document or another document entirely. Even though it should be avoided, there is no great harm done in a poorly authored summary. Users might even become familiar with sites/authors who produce valuable table summaries and those that do not. The time lost on a poor summary is small when compared to the overall time needed to comprehend a complex table. The existence of poor table summaries suggests that more needs to be done in the HTML5 draft, in other W3C WGs, and elsewhere to inform authors about how to author such summaries. 1) More should be conveyed to authors about the difference between a caption and a summary and how they should not be authored redundantly. 2) Authors should be told not to include information easily discerned through algorithm such as the number of columns and number of rows. 3) For simple tables authors should be advised that a summary may not even be necessary. And so on. The point is that poorly authored table summaries do not indicate a need to remove facilities from HTML, but instead the need to convey to authors the importance of authoring effective table summaries. Take care, Rob [1]: <http://malform.no/html5/summary+css> [2]: <http://www.w3.org/Bugs/Public/show_bug.cgi?id=5756> [3]: <http://esw.w3.org/topic/HTML/RicherUIAccessToHTMLData>
Received on Wednesday, 25 February 2009 06:48:28 UTC