- From: Ian Hickson <ian@hixie.ch>
- Date: Mon, 29 Jun 2009 06:07:24 +0000 (UTC)
- To: Shelley Powers <shelley.just@gmail.com>
- Cc: public-html@w3.org
On Sun, 28 Jun 2009, Shelley Powers wrote: > >> > >> Actually, those are not "studies", Ian. You and Philip accessed some > >> publicly accessing information found online, and ran some queries and > >> look at the data, and then formed your conclusions. > > > > If you have something better, I'm all for using that. > > > > In the meantime, I'll use what we have, as it is better than nothing. > > But it could be worse than doing nothing. Using what data we have is not worse than doing nothing. > You have stated that summary is harmful. You have provided no proof of > harm. No, the so-called "studies" are not a conclusive proof. They are convincing enough to me. You are certainly welcome to disagree. > I ask in return: where are the studies you plan to take to demonstrate > that collapsing summary into caption will be the superior solution? I am not planning any such studies currently, though I would be happy to entertain any ideas you may have. I could offer to use Google's usability lab to perform studies; would you accept the results of such a study? What studies do _you_ plan to take to demonstrate that summary="" is the superior solution? > >> Now, this is a little naive. I think you have a bias against those > >> with years of experience and training, and it clouds your own reason, > >> Ian. > > > > In the unlikely case that this is true, I actually ignore the source > > of e-mails when responding to feedback. You will notice for instance > > that the issues list doesn't list who sent what: > > > > http://www.whatwg.org/issues/ > > > > This is intentional just in case I am biased against one person or > > another, to avoid that bias. > > I'm reluctant to comment on anything from the WhatWg side, because > frankly, I find much of it lacks rigor. The specification that proposes to not include summary="" and that recommends the use of <caption> instead was developed on the WHATWG site. In fact the entire spec was developed using the feedback published at the URL above. All the feedback you send ends up there too, for instance, after being anonymised. In any case, my point is that I ignore the provenance of comments when responding, so that the biases that you accuse me (or any others for that matter) of do not affect my work. > However, perhaps if there were more people involved in both the effort > and the decision process, you wouldn't have to resort to such trickery. > Because this form of trickery will not succeed. I'm sorry, you've lost me. What trickery? > One is known by both our words and our interests. If there is an issue > related to, say, RDFa, one can assume you remember those people > interested in RDFa. Same with summary and so on. My point is that it doesn't matter who is interested or who is not, since all I look at is the arguments and data that is presented. In the discussion of data annotation, for instance, I only looked at the use cases and so forth _after_ stripping all information about who wrote them. If you look at the e-mails I sent on the subject you can see the text that I used to derive the solutions. It doesn't mention who asked for what. The "who" is irrelevant to the technical goals. > >> If there is a debate between Paul Krugman and a 12 year old, you'll > >> have to forgive me if I give more credence to Paul Krugman. > > > > You'll have to forgive _me_, then, for treating them identically and > > applying the same standards to both. > > Again, I would say this reflects a deep seated bias against expertise. Surely treating everyone the same would be a position of neutrality, not a position of bias. Expertise is not a license to skip reasoned arguments and research. There is not, and there should not be, any difference in how an expert or an amateur is treated. An expert astrophysicist doesn't get to just claim he saw a new comet, he has to document it, just like the amateur. An expert programmer doesn't get to just tell the computer what he wants his programs to do, he has to code them just like the amateur. A professional basketball player doesn't get to just toss the ball mostly in the direction of the basket, he must get it in the ring just like an amateur. The difference between an expert and a non-expert is that the expert can be expected to be more competent at explaining his reasoning, at showing his research, at documenting his work. Experts are better than amateurs. That's the only difference. We must still treat them the same. > >> If anything, I see a decreased interest in providing any specialized > >> help. > > > > If by that you mean that there is a tendency to prefer built-in > > accessibility (like <input type=date> rather than bolt-on > > accessibility (like <img alt>) then yes, that is intentional [...]. > > Now, we're seeing a new criteria being introduced into the discussion. This isn't new, this kind of design has been part of HTML5's development since the very beginning. It's how most of Web Forms 2.0 was written back in 2003/2004. Heck, even then it's not new -- it underlies how HTML was designed all the way back to the first version, as far as I can tell. It's the whole reason for arguing for separation of presentation and semantics. > What forms the basis for your criteria of "built in" versus "bolt on"? > What are the studies you've conducted that support this particular > preference? I had no idea anyone actually thought bolt-on accessibility was better. That idea is quite novel to me. Off the top of my head I can't think of any public research that demonstrates this particular principle quantitatively. Arguing for bolt-on accessibility mechanisms is like saying that it is better for a building to have stairs and a ramp than for the building entrance to be at street level. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Monday, 29 June 2009 06:08:03 UTC