Nonono, you mean to say if Ian Hickson is incapable or unwilling. After all, he is the sole dictator over the HTML5 specification, so if he doesn’t want something, good luck trying to convince him. Ridiculous.

http://masinter.blogspot.com/2009/05/structural-bias-standards-and-elsewhere.html

One of the key things you stated however was: “There’s lots of room for interpretation and judgment calls in deciding what would be the optimal markup for the spec to suggest…” and it is here that I and others take umbridge.

The interpretation of the data (and reasons for, as well as possible solutions to) did not happen as a dialog between end users & subject matter experts and the specification authors, but instead was decided upon by a small group of people who emerge with a “solution” that we must simply accept. This is fundamentally wrong, and is the source of my continued disdain for the entire process. We are expected to take the ‘expert’ interpretation of the success or failure of accessibility features simply on the say-so of data interpretation by a few select people. When a larger collection of subject matter experts review the situation(s), the data available to them, and then discuss it in an open and transparent way – AND THEN ARRIVE ON A CONSENSUS POSITION – only to have it derisively dismissed on the IRC channel within minutes of the recommendation being publicly released… No, there is a real problem here that is quite obvious to even those who have arrived late to the discussion, or are simply interested by-standers watching this process.

For data to be properly interpreted requires a certain amount of subject matter experience and expertise. And quite frankly, while Ian and Anne and Lachlan and Mark and Maciej and Henri and yes you (to name but a few of the more outspoken contributors) have considerable knowledge and experience with web technologies, when it comes to web accessibility you are not yet experts – oh sure, you might have opinions (who doesn’t), but often those opinions are not fully based upon real experience. And that’s OK, nobody can be an expert at everything and web accessibility is complex, nuanced and often subjective. But make no mistake about it, as those folks that vocally set aside (or dismiss) the expert opinion of recognized practitioners, advocates, experts and end users, they are, in effect, claiming to be more knowledgeable than those actual experts. This is the real root of the disagreement – who is better placed to interpret the ‘data’ and make recommendations?

The vast majority of bogus values will not be heard by screen reader users that support summary, as they are on layout tables, and screen readers that support summary also filter out layout tables. So when a user does hear a summary announced it will most probably be useful, although this will be a rare occurrence.

“Mark Pilgrim recommends the use of @summary in tables” – it’s easy to demonstrate that claim is flawed, by pointing at http://krijnhoetmer.nl/irc-logs/whatwg/20090604#l-706 (“my opinion on accessible markup has changed since i wrote “dive into accessibility”" … “the only effort has been in defining markup (usually, accessibility-specific markup) that purports to solve certain problems, but there’s no followup to determine if those particular solutions actually DO solve those particular problems”).

As far as I’m aware (though I haven’t looked at it closely myself), the data shows that a random user viewing a random web page trying to read summary attributes will waste their time (getting an unhelpful value (“Layout Table”), getting garbage (“Ripple.AutoProg.Unit3.MakeTree2.SetCategory”, “pid5673054″)) much more often than they’ll get something really useful. That’s important information for us to know, since it tells us there’s scope for improving overall accessibility across the web if we can encourage authors to use different markup that will have a higher proportion of useful content (perhaps by telling authors to make the text visible to all users, so they’re much less likely to stick garbage in there) without greatly reducing the absolute amount of useful content. There’s lots of room for interpretation and judgement calls in deciding what would be the optimal markup for the spec to suggest, but the data itself seems valid regardless of any opinions or spin, and any decision should take it into account.

“And as Laura Carlson linked in the public-html mailing list, the page listing all of the issues about @summary also references Ian’s use of Google data:”

That page just references a general-purpose data mining Hixie did in 2005. It does not follow that Hixie used that data in decisions about summary=”".

I have not seen Hixie reference any Google data when discussing summary=”".

According to the publicly available data then, Mark Pilgrim recommends the use of @summary in tables [ http://diveintoaccessibility.org/day_20_providing_a_summary_for_tables.html ] and Ian Hickson indeed *advocates* using the @longdesc attribute [ http://www.hixie.ch/advocacy/alttext ] – yes, data mining can be fun, but as now ‘proven’, can be used to spin whatever story you wish.

(It will be interesting to see what the IRC log does with this…)