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

>> > > Ian, I don't think that it is fair to imply or assert that longdesc
>> > > and summary do not work in practice.
>> >
>> > All the evidence we have collected indicate that they are in fact
>> > complete and utter failures. I'm not sure how "fairness" enters the
>> > discussion; this is an observation backed up by every objective study
>> > that has been cited so far. We do the aforementioned population a
>> > serious disservice by pretending otherwise.
>>
>> Fairness as in "fair dinkum". Your "utter failure" assertion is your own
>> assessment of a set of data which I am given to understand is in fact a
>> private collection.
>
> There have been a number of public studies also. I believe in fact that in
> the case of summary="" the only numbers that we have published were based
> on publicly verifiable studies; I don't think I've ever actually made any
> public statements regarding any privately collected data on the topic. (I
> may have, but I don't think I did.) For some time now, I've been using
> Philip`'s publicly-collected and analysed data primarily, only supporting
> it with spot checks using data from Opera and Google to see if his results
> are reproducible (which so far they always have been).
>
>

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.

Neither of you controls how the data is collected, so the raw data is
flawed. Plus, both of you base your conclusions on a specific
hypothesis that supports your own biases. Neither of you has actually
conducted an unbiased "study". Neither of you even are willing to
contemplate that what you are measuring is not the data that indicates
either success or failure.

When it has been pointed out that the data is flawed, because the
summaries are attached to HTML tables that are, themselves, used
incorrectly, you basically blow off this very valid point -- because,
again, it does not support your hypothesis.

So no, you have not "conducted studies", you've only hacked some data
you found online.

>> Moreover, the proponents of both summary and longdesc disagree with your
>> assessment.
>
> Disagreeing by assertion the results of objective studies isn't "fair"
> either. I could assert that the financial markets have done nothing but
> grow in the past three years, but presumably you would dismiss such
> statements as groundless. This is, IMHO, no different.
>
>

To repeat, neither you nor Philip have conducted "unbiased" studies.
You have, as you've admitted, a bias against "hidden" metadata. You
share this bias with others, such as James Graham. I'm not sure if
Philip also shares this bias, but I believe he does.

So one could say that rather than work to define the parameters of a
truly unbiased study, you looked at some data, it supported your bias,
and you stopped at that point.

Others may define a different set of parameters. A good example would
be AT implementation. Rather than looking at how authors use the
attributes, a measure of success could be AT implementation. In that
case, than @summary could be seen as a success. Now, you may say this
isn't a correct measure of success, but why should you be the one to
determine what is or is not a proper measurement of success?

A third measure of success could be satisfaction of those who use
screenreaders, and whether they appreciate having the values, as they
are currently defined. This type of study is expensive, though, and
usually requires specialized questionnaires, as well as lab testing to
really assess the results in such a way that a conclusion can be
derived from the results.

Most studies, especially when it comes to human interaction, are
usually managed by people specifically trained in performing these
studies. They understand how to not only pull out the parameters that
make a true measure of success, but they know how to then turn those
parameters into an effective study, and then run the study
objectively.

So, please, stop saying anything about running an objective study.


>> I could agree that the publishing market has not yet adopted these
>> features as fully as the AT market and its supporters would have liked.
>
> The problem isn't so much lack of adoption so much as the overwhelmingly
> incorrect use of the features when they _are_ used.
>
>
>> I could agree that the technology is immature.
>
> How long would you estimate it should take for such an attribute to
> mature? How long before we decide it's been too long? 3 years? 5 years? 8
> years? It's been a decade.
>

And again, one has to look at all of the data, and what all of it implies.

The data sampling is obviously flawed. For most of the incorrect uses
of summary, you had incorrect uses of HTML table. I believe that HTML
tables have been around since HTML 3.2. That's over a decade isn't it?

So, one can't necessarily look at the length of time and say, "This is
an effective parameter when testing the success of this HTML
attribute", unless one looks at the overall picture of HTML use, and
somehow filter out the extraneous flaws.

And again, who is to say that length of time that the attribute is
available in spec (as compared to implemented in AT technologies, and
as compared to length of time implemented in HTML authoring tools) is
a true parameter to test whether the attribute is successful or not?
Just saying so, doesn't make it so.

> Consider another attribute, like "axis". This is an attribute intended for
> accessibility purposes, just like "summary". Is _it_ mature? Should we
> keep it? Drop it? Why?
>
>
>> But the technology does work when useful content is provided.
>
> Granted. However, useful content is provided in such a small fraction of
> cases where content is provided at all, that the features are unusable for
> their original purpose by the people for which they are intended.
>

Again, though, you are basing your judgement on whether to include
support for the attributes on your own bias that hidden metadata is
"bad", and therefore examining only one measurement of the success of
summary. When others point out that there may be more than one measure
of success, rather consider reassessing your assumptions, you cite,
and re-cite the same block of data, and then same crude measurements
and express confusion what others are not finding it sufficient.


> This was my original point: The large number of people on the Web with
> special needs are exactly the people I want to help. However, we have to
> *actually help them*, not just provide solutions that theoretically might
> help them but in practice do not (such as longdesc, summary, etc).
>
>

I have to question the effectiveness of your help. I have not seen any
real move to specifically help those with visual impairments. What I
have seen is that you're more interested in exposing more data to
those who do not have any visual impairment: include a visible link,
incorporate the text into caption so everyone can see it. Neither of
these is engineered _specifically_ to provide help to those with
visual impairments.

>
>> > > Since you argue that browser makers are the ultimate gatekeepers for
>> > > visual representation of HTML, why do you not allow the same role
>> > > for AT makers?
>> >
>> > AT vendors do have that role. It's not up to us to "allow" or
>> > "disallow" it; it's a fact. Implementors have the ultimate veto on any
>> > implementation requirements we put in our specs not because we allow
>> > them to, but because in every literal sense if they don't want to do
>> > what we tell them to do, then they don't have to.
>>
>> I would never suggest that it is up to us to allow or disallow.
>

But you do provide conformance requirements for authors, and authoring
tools. Much more so than was available in HTML 4.x. At least, that's
my reading. How much this will impact, I don't know.

And when you redefine an element, like caption, than you do generate a
disconnect with backwards compatibility.


> You asked why I don't allow the same role for AT vendors as browser
> vendors. That is what I was referring to. My apologies if I misunderstood
> what you meant. Could you clarify what you meant by this?
>
>
>> I have been consistent on that with regards to HTML. In fact, I have
>> long been a supporter of employing attributes, like longdesc and
>> summary, to convey ancillary information to applications which care to
>> employ it. I am fairly liberal when it comes to attributes in markup
>> because they are so much easier for an application to ignore if they so
>> choose.
>
> Unfortunately, it has been demonstrated that this particular approach
> doesn't work in wide deployment on the Web, because of the small fraction
> of the authoring base who specify these attributes, a large proportion
> specify useless values that are hard or impossible to programatically
> distinguish from useful values, and thus these attributes in fact end up
> _not_ being easy for an application to ignore unless they ignore them
> wholesale (at which point the value of the attribute is lost, and we would
> be doing authors a favour by letting them know that providing the
> attribute at all is a waste of time).
>
> We have to adapt our design philosophies to the results we can see on the
> Web. This means abandoning design ideas that are demonstrated to not work,
> emphasising design ideas that do work, and focusing on creating new ideas.
>

But you have to do so for all web users, not just your small group,
with your own obviously strong biases against non-visible web page
elements.

>
>> Again, I am not suggesting enforcing anything. Rather, I am suggesting
>> enabling and empowering AT implementors.
>
> I am suggesting they have ultimate power already. :-) If we specify
> something and they decide it's worthless, they're not going to implement
> it. (Witness the "axis" attribute in HTML4, for instance.)
>
>
>> Proponents of longdesc and summary simply want to be able to use two
>> attributes to convey useful information.
>
> Sure, and if they were the whole authoring community, that would work
> great. But they are not, and we have to look at this from the point of
> view of the wider user community, not the few authors who are so familiar
> with these issues that they are working group members.
>
>

One could say the same of the blind, too, couldn't one? The needs of
the few, as compared to the needs of the many?

>> It is true that those attributes will be misused on some/many/most HTML
>> pages, just as other HTML attributes are often misused. But that doesn't
>> mean that it won't be useful when it is.
>
> Actually, that's exactly what it means. When the overwhelming majority of
> the data is bogus, you cannot know when it is not, and thus even good
> values become useless.
>
> If a drink vendor made good drinks 1% of the time but 99% of the drinks
> tasted like mud, and you couldn't tell until you'd tasted it, would you
> say the drink vendor was useful? Would you continue to purchase drinks
> there?
>
>
>> That may not seem like a very satisfying engineering solution, and it
>> isn't. But so what? If it only helps a few people to read a good book or
>> a newspaper or their company newsletter, then haven't we made the world
>> a better place.
>
> It's not that >99% of the relevant _users_ can't use these attributes and
> <1% of the relevant _users_ can use these attributes. It's that 100% of
> the users will find them useless >99% of the time, and they have no way to
> know ahead of time which the <1% of the cases are, and therefore they will
> act as if the attribute is useless 100% of the time.
>
> Furthermore, with both longdesc="" and summary="" there are ways to make
> the data available that don't in fact have any of these problems. You can
> provide an explicit link visible to all, and you can provide a summary of
> the table visible to all. These solutions would have significantly less
> bogus data (because the authors would see them), and so users would know
> that they are likely to be useful. It also provides these useful
> descriptions to all users (universal access), thus benefitting even users
> who might make use of such help despite being sighted (e.g. users with
> cognitive difficulties might find an introduction to a complex table
> useful despite being able to read the page fine, and in fact even "normal"
> users would sometimes find such help useful, as was demonstrated on some
> pages discussed a few weeks ago).
>

Again, though, this reflects your bias against hidden data in the web
page. Perhaps your hypothesis that making all of the data available
will be sufficient, but you've not run any alternative study to test
this hypothesis.

>
>> And at what cost? Some HTML attributes that most browsers will ignore
>> and some will support.
>
> The cost of these attributes is that people who _do_ want to help authors
> will spend time writing help text that will be ignored by many of their
> users. Instead of improving accessibility in ways that actually improve
> accessibility to many users, authors will think they have improved their
> site's accessibility while in fact having done little to truly help users.
>
>
>> > For requirements that apply to ATs, the AT vendors have ultimate and
>> > absolute power.
>>
>> So, are you suggesting that you would listen to guidance directly from
>> representatives of the AT vendors but do not consider the W3C's own
>> experts to be adequate representatives?
>
> I think the W3C's own experts would be the first to admit that they do not
> represent the accessibility tool vendors and would compete with me for
> first place to asking AT vendors to take part in these discussions.
>
> Incidentally, expertise is not a license to skip reasoned arguments and
> research. There isn't anything special about experts in the HTML5
> development process; the only difference between an expert and a
> non-expert is that the experts will have an easier time explaining their
> arguments and obtaining supporting data. Experts have more influence than
> non-experts not because they are labeled "expert", but because they are
> more convincing in their arguments, they are more adept at finding
> relevant research, they have relationships with people who can provide
> corroborating evidence, and so forth.
>

I'm not an accessibility expert, but I hope that my arguments in this
email are reasoned. Again, though, what is the determination of what
is reason? That I provide a solid counter-argument? Or that I agree
with you?

> There is no difference between an expert who posts anonymously to the
> mailing list while pretending to be a 12 year old student, and the same
> expert posting as someone who lists six professional organisations and
> three doctorates in his signature. They both have to argue their case like
> everybody else, and they are both going to be exactly as convincing.
>
>


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.

The real argument should be not that an expert is writing anonymously
as a 12 year old, but there actually is a 12 year old in debate with
an expert. You may like what the 12 year old says, but that doesn't
mean that 12 year old has some keen insight. Sometimes the experts say
truths that are unhappy or painful, but that's because their years of
experience and training has helped them see beyond the trivial.

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.


>> But we are being asked to patient while a small community of
>> under-funded associations and companies build the critical mass of
>> technology and content to enable people to read or listen to an
>> increasing volume of useful content.
>
> It should be noted that the proposals I have put forward for HTML5
> actually help with this, because they make it unnecessary for the AT
> vendors to expend any resources specifically on the issues of longdesc=""
> and summary="" (a big effort, especially considering the difficult problem
> of distinguishing useful values from useless values), allowing them
> instead to focus on features used on many pages, like links and captions.
>

Again, though, I see nothing proposed here to specifically help those
with visual impairments. If anything, I see a decreased interest in
providing any specialized help.

>
>> As far as discovering useful content on the web, I am not in a position
>> to comment. I am willing to believe that longdesc and summary are not
>> used correctly in some/many/most pages today. But if we drop these
>> attributes and then adopt a new approach, the AT developers will be set
>> back again.
>
> Not if they already support the new approach, as is the case for both
> links and captions, which are the solutions HTML5 encourages today.
>

Your caption solution is incorrectly applied, regardless of
accessibility issues. You're redefining the purpose of an existing
element. Not clarifying, redefining. I didn't think that was an
acceptable approach to take if one is interested in backwards
compatibility.

Shelley

Received on Sunday, 28 June 2009 23:25:04 UTC