Comments on: Comic Update: Who Really Is the Wizard of HTML5?

By: Laurens Holst

Laurens Holst — Mon, 26 Oct 2009 10:07:23 +0000

@Kyle: “If the HTML5 WG is incapable or unwilling to work with the other Working Groups on important issues like accessibility”

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.

By: [Wild Conjecture] Chrome OS as I imagine it – The Educated New Village Boy

[Wild Conjecture] Chrome OS as I imagine it – The Educated New Village Boy — Sat, 11 Jul 2009 00:51:48 +0000

[...] for the browser community to move towards HTML 5. To the extent where some are accusing them of manipulating the standards process to get what they want in. With HTML 5, multimedia capabilities would be built right into the [...]

By: Larry Masinter

Larry Masinter — Wed, 24 Jun 2009 16:56:39 +0000

Power corrupts: even those who are able to separate their personal opinions can be part of a biased process:

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

By: John Foliot

John Foliot — Tue, 23 Jun 2009 22:26:01 +0000

@Philip Taylor: Overall, I am in agreement with what you are saying – I deliberately sought out ‘conclusive proof’ that @summary and @longdesc should remain in HTML5, as two of the main spokespersons for the WHAT WG wrote as such, simply to prove that raw data alone is not that useful. For what it’s worth, my feelings regarding longdesc have not change much, although I recognize that it is both misunderstood and under-utilized (and I did not need to crawl Google’s index to arrive at that conclusion); perhaps with the aria-describedby attribute we will have a better (or second) opportunity to get the education part right. I hope. Meanwhile, I remain with the belief that we should continue to support an accessibility attribute until such time as we can prove that it’s replacement is in fact replacing the older attribute… like all languages, it should just fade from usage, rather than be decreed abolished.

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?

By: Philip Taylor

Philip Taylor — Tue, 23 Jun 2009 22:07:12 +0000

Steve: Ah, I forgot about that. That seems like a good example of how the data could (and should) be improved, by filtering out layout tables similarly to how screen readers do it and then seeing what’s left over. (I haven’t been keeping track of all the list discussions – has anyone pointed to a description/implementation of an algorithm that would be similar to modern screen readers? It’d be nice to have that implemented in Java so it can be run over a wide set of pages to see what overall difference it makes in practice.)

By: steve faulkner

steve faulkner — Tue, 23 Jun 2009 20:36:32 +0000

philip taylor wrote:
“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.”

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.

By: Philip Taylor

Philip Taylor — Tue, 23 Jun 2009 19:42:38 +0000

John: Any reported data should be subjected to critical thought and discussion, and not accepted blindly, but nor should it be rejected blindly. If someone thinks the data itself is flawed, they should argue why and suggest ways of getting better data, but in the meantime it seems to be the best data we’ve got and it allows us to make more informed decisions than if we had no data.

“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.

By: Ian Hickson

Ian Hickson — Tue, 23 Jun 2009 18:55:24 +0000

I haven’t referenced any internal data in years, actually; pretty much ever since Philip` and others started doing public research.

By: zcorpan

zcorpan — Tue, 23 Jun 2009 18:20:57 +0000

About longdesc: noted.

“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=”".

By: John Foliot

John Foliot — Tue, 23 Jun 2009 17:07:49 +0000

What it comes down to is this: a number of technologist are crunching data to support their hypothesis and/or to justify how they choose to implement (or not implement) certain features. As most of us know, you can make numbers (and ‘raw data’) say anything with the right kind of spin, and spin-meisters such as Mark Pilgrim (the author of the longdesc-lottery blog posting) are very good at doing just that. (In fact, if you read the entire IRC log at http://krijnhoetmer.nl/irc-logs/whatwg/20090623#l-187 you will note that Henri Sivonen asks where Mark’s propaganda posting have been of late).

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…)