Fwd: Why I don't attend the weekly teleconference (Was: Input on the agenda)

Sorry, forgot to cc group

---------- Forwarded message ----------
From: Shelley Powers <shelley.just@gmail.com>
Date: Mon, Jun 29, 2009 at 8:21 AM
Subject: Re: Why I don't attend the weekly teleconference (Was: Input
on the agenda)
To: Ian Hickson <ian@hixie.ch>


than nothing.
>>
>> But it could be worse than doing nothing.
>
> Using what data we have is not worse than doing nothing.
>

Using data incorrectly, in order to support a bias is not a better choice.

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

Yes, but disagreement here means some form of action. We'll most
likely take a vote, but that defeats the point I'm trying to make, in
that   you don't seem to be aware of how your own biases are
influencing how you interpret data, and how you're editing the HTML 5
specification.


>
>> 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?
>

No, Google is a now a browser company, and with some recent
statements, the company is showing a particular bias about how it
believes the next version of HTML 5 should be.

And frankly? Google is not famous for usability.

I would rather have IBM's usability labs, which I studied when I was
getting my degree in IO psychology. The company had some of the best
usability studies ever, though I imagine these have had to be cut
because of the times. Probably cut years ago.

I'm only speaking for myself, though. Others may be willing to accept
Google usability studies, as long as we can review the procedures
used, and have access to the raw data.

> What studies do _you_ plan to take to demonstrate that summary="" is the
> superior solution?
>


Actually, I don't believe we need to, not unless there's a plan to do
the same with every last bit of the HTML 5 spec.

There are few studies, if any, about what is included in the HTML 5
specification, and what is pulled. I'm not sure why you're demanding
an exceptional level of rigor for accessibility markup that you're not
requiring for other markup.

But you keep referring to your skimming of collected web data as a
"study", and my point is that it is no such thing. And that perhaps it
is time that we stop pretending that a decision on summary has been
based on some kind of scientific research.

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

Ian, you are not listening. I find that does not make a good
specification editor.

Unless you suffer a disease that means you forget everything every
single day, you know who is either interested in an issue, or if you
are entering issues people bring up in comments, you "know" who the
submitter is.

Why would you believe otherwise? Do you consider yourself some kind of
superman, who can leap human fallibility at a single bound?

So your suggestion of lack of bias is, frankly, silly. And I'm very
concerned that you seem to believe that you are operating without
bias. I would rather a person own up to their biases, and ensure
others' input whenever issues related to that bias arise, then someone
who pretends that they've eliminated all bias, and continues making
isolated decisions.

You mentioned the semantic metadata use cases. Well your bias in that
regard caused you to misread several of the use cases. And then you
used this misreading to form some new microdata section, which we've
just seen has very little support. All because you have a basic bias
against RDFa, or namespaces, or whatever, and you make the ultimate
decisions.


>> 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?
>

See above.

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

Oh good lord, Ian, wake up and smell the reality. I am astonished that
you think you have somehow eliminated bias because you remove names
from issues you yourself record.


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

But unless you suffer that aforementioned disease, you do know who is
interested. Of course you do. You just sent me and a small group of
other people questions about Canvas, because we've all expressed
interest in accessibility issues. So you know who is interested in
these topics.

More than that, it doesn't eliminate your biases about "hidden" data,
which you don't really back up with any empirical research. Other than
looking at data at Google, or elsewhere.

The only way to help lessen bias is involve others in the decision
making process, but you effectively bar entire groups of people from
such. Now we're having to do a vote just to address this,
specifically. And there will most likely be formal objections about other
aspects of the specification, too.

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

But you make the call as to what is reason, you make the call as to
what is a good argument, you make a call as to who you listen, you
make the call, as to the people who you respect enough to actually
change your mind. And you do so based less on argument, and more on
how similar they are to you.

Twenty something able bodied men, with varying computer science
background, and sharing an astonishingly significant geographical
similarity, most of whom are either in school, or who work for
companies building browsers. They are more interested in new toys and
web applications, and building the web OS than providing a good,
overall specification that serves the needs of all people.

It's the same people who are bloating the browsers to the point that
the things fail all too often.

This is who HTML 5 is designed for. Because you are biased towards
people who think like you.

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

Again, though, you act as filter to the experts, demanding that the
expert use your assessment of what is reason and rationality, your
biases, even your terminology. People keep suggesting solutions, and
you keep responding with questions about asking their feedback,
because you need solutions.

You can't "see" their viewpoint, you don't hear what they say, you
show little but veiled disdain for most of the arguments, and you and
your buddies snark about on the WhatWG IRC like a group of
particularly nasty school boys.


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

Then provide links to relevant discussions. I've noticed that most
people in this mailing list provide links to the relevant arguments.

>
>> 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, I asked a direct question, and you ran all around it. I repeat
the question here:

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?

Shelley

Received on Monday, 29 June 2009 13:25:33 UTC