- From: Shelley Powers <shelleyp@burningbird.net>
- Date: Tue, 09 Jun 2009 06:31:21 -0500
- To: Henri Sivonen <hsivonen@iki.fi>
- CC: "public-html@w3.org WG" <public-html@w3.org>
Henri Sivonen wrote: > On Jun 8, 2009, at 17:53, Shelley Powers wrote: > >> Henri Sivonen wrote: >>> Indeed, summary="" as a sign of a layout table seems useful assuming >>> that it is better supported by existing software than >>> role=presentation, but I wouldn't count summary='' as an example of >>> the attribute being used to give a longer-than-caption summary of a >>> data table. >>> >> I'm sorry, I'm not sure what your argument is here. > > I'm observing that in the light of 'best practice' how @summary is > supposed to be used, only the empty summary attributes comply but > actual longer-than-caption summaries of data tables are nowhere to be > found in Philip's data. (summary="Calendar" may be useful but doesn't > match the best practice put forward.) > I don't believe a requirement for summary is that it must be longer than caption. Your argument is looking for a fault where there is none. >>> Which raises the question: If @summary is almost always used on >>> layout tables instead of data tables, is it solving the problem that >>> it is supposed to solve: providing a summary for complex data tables? >> >> Henri, your argument's logic is flawed. The majority of table usage >> is for table layout, so it's not surprising that the majority of >> summary usage is on tables being used for layout. Your logic states: >> >> Most HTML tables are being used for layout. >> A certain percentage of HTML tables have an associated summary. > > We shouldn't assume that layout tables and data tables use summary as > often. If summary were used correctly, we should expect all non-empty > summaries to be on data tables! > And we would expect there be no layout tables, either. The web is imperfect. >> Therefore, summary isn't solving the problem it is supposed to solve, >> which is provide a summary for complex data tables. >> >> Non sequitur > > My point is this: > > If @summary were used the way it is said it should be used, we should > find a lot of summaries of like "Rows contain destinations, traveling > dates, and grand total. Columns contain expense category and total. > The first column contains merged table cells." and virtually no > summaries like "layout table". > > Yet, the data shows virtually *no* summaries of the best practice > kind. It's not that there's a mass of incorrect use in the data. It's > that there's *no* best practice-conforming use to be found at all. > (Well, maybe there is if you sift through the data harder.) > > Even if we accept that @summary has a non-zero success, it sure seems > to have an enormous waste rate (people toiling away adding pointless > summaries to be discarded by JAWS). > You keep using one metric, an arbitrary count, as your measurement of success, Henri. And I keep repeating that, especially when it comes to issues of accessibility, that counts and empirical observations are not the most effective determinant of what counts as success. Sometimes a measurement of success is for those who need such features to be assured that they are not forgotten; nor that those who would create a new generation of web pages discount their challenges by removing the few features created specifically for them. How people perceive the actions of the HTML WG become just as much a metric for success when it comes to meeting needs and demands for accessibility. Regardless, I will repeat: the sole purpose behind removing @summary seems to be that it will be "harmful". No one has provided a case for the harmfulness of this attribute. And the group responsible for ensuring web accessibility has not only stated that they disagree with the claim of harmfulness, they have made a specific request to have it re-instated. According to the charter governing the HTML WG, the course is clear. >>> Obviously, tables are used "incorrectly" so often that it makes more >>> sense to develop ways to deal with the incorrect use on the client >>> side (detect layout tables and linearize them for AT use or for >>> small-screen mobile use) than to try to "educate" the whole world >>> not to use layout tables. I don't conclude that the solution to use >>> of tables for layout is education. >>> >> >> What does this have to do with @summary? I agree, disregard the table >> components when parsing a layout table. > > I thought you brought up the incorrect use of tables to draw a > parallel with the need to educate. If that's not what you meant, > please disregard that paragraph. > I don't care what you all do about layout tables, though I noticed the discussion in the #whatwg about including algorithms for tool makers to follow when dealing with non-data tables. Of course, such is outside of the scope of the charter for this group, but that's neither here nor there. To return to the only point that matters: the reason we're given why @summary was removed is that a claim was made that it was "harmful". There is no proof of the harmfulness of the attribute. Unless there is another reason to remove this accessibility markup, I then remind the group of its charter commitment to cooperate with other groups, including the W3C WAI Protocols & Formats. Again, my usual disclaimer: I am not an accessibility expert, not part of any group, giving my own opinion as a web professional, and so on. Shelley
Received on Tuesday, 9 June 2009 11:32:01 UTC