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

At 09:01 PM 6/28/2009 +0000, Ian Hickson wrote:
>On Sun, 28 Jun 2009, Murray Maloney wrote:
> >
> > I think that the public is largely stuck with whatever the browser
> > makers do.
>
>In that case, my original statement stands. If we want to make the spec
>actually match what is implemented, and not be an especially dry work of
>science fiction, we have to write what the implementors want to implement.
>They do in fact have ultimate veto on the parts they implement.

Well, just because some/most/all browser implementations are not using a 
few attributes does not make those attributes science fiction. I think that 
if we can both avoid hyperbole, we might be able to have a useful and 
insightful discussion about how to really solve these problems, both social 
and technical. It is true that browsers can chose to ignore features within 
HTML. That does not render the features obsolete to other kinds of tools, 
or user agents. Can we agree on this much?


>(I personally don't think it's as dire as you seem to indicate; as Boris
>indicated, there is the opportunity to fork clients, there are vendors who
>really do care about users on the aggregate, there are vendors for whom a
>majority market share position would actually be considered a failure,
>and, frankly, the users are far more able to tell what they like and what
>they don't like in their browsers than in their banks.)
>
>
> > Lots of little guys have been justifiably concerned about banking
> > practices, but we have not been able to make that market behave in a way
> > that ensures sustainable growth, steady employment or dependable
> > retirement funds. We cannot trust our governments, banks, regulators,
> > investors and borrowers to manage their/our money well enough to
> > guarantee a stable world economy. Yet, you are suggesting that the
> > market will guide the browser makers.
>
>I'm not making any judgements about whether this is the ideal situation or
>not. I'm saying that this is the way it is whether we like it or not.
>Unless the W3C gains some kind of enforcement power, the implementors will
>_always_ have the ultimate veto, swayed only by their desire to gain
>market share.

I can agree 100% that nobody has to implement any feature in HTML.

Can you agree that browsers are not the only viewports onto HTML?


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

If the universe could provide you with evidence that there is sufficient 
useful data extant to justify the existence of longdesc and summary, how 
much data would that have to be? If the Wall Street Journal and its sister 
news providers began providing all of its feeds with useful AT metadata, 
would that tip the scale? What if several state/national education systems 
were to make their curricula to their students available with useful AT 
metadata? What if state/federal financial reports employed My questions are 
not rhetorical? There's more than one way to skin a cat, and if all it 
takes is to get somebody to turn on a bit of XSLT and populate a few web 
sites, then maybe you can get your data and everybody will be happy. So, 
seriously, how much data from  a legitimate publisher would warrant a 
reversal of your position.

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

Well, it's a bit different. Verifiable data about the financial markets is 
available to all and a plethora of pundits and analysts are ever ready to 
pronounce myriad opinions on the meaning of almost every data point. With 
these AT attributes, the accessibility community is trying to educate 
publishers and it is taking a long time.

[Frankly, the browser vendors could win a lot of good press by stepping up 
with the big publishers and provide better accessibility for everybody. A 
well-written table summary could help a lot of people, especially in 
financial reports.]

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

Which relative percentages could be overcome tomorrow if the right 
publishers flip a switch.



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

I see your point. But I didn't say that the markup was immature. The markup 
is quite mature and processing expectations are simple enough to 
understand. But the technology has not matured due to a social problem, not 
a technical failure.


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

Well, that's not fair either. :-) Axix/axes happens to be a favorite of 
mine and was the subject of a chapter in an SGML book I completed for Yuri 
Rubinsky in 1997. If browsers today were able to process axis/axes and its 
use were adopted more widely it would aid the comprehension of tables. I 
would keep it in because it costs you nothing to include a feature that you 
do not expect many/any browsers to implement. If/when they do, users of 
such tables would benefit immensely. Until then, other processing tools 
would still be able to read and write axis/axes values for their own purposes.

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

Can you agree that longdesc and summary are not in themselves faulty and 
that the real problem is a social problem related to lack of useable data.



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

But that argument will apply to whatever solution is proffered, won't it. 
We can never be sure that a text input attribute will contain the right 
information unless we so constrain the attribute as make it unusable as a 
general text container.


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

Again, just because the browser doesn't use something, doesn't mean nobody 
does.



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

I'm not sure what that means. Could you please rephrase that.



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

You assert that I cannot know. But there are ways that I can know that a 
given publisher, perhaps the one through whom I receive my Reader's Digest, 
is providing me with useful data. Or perhaps I could use 
profile="http://www.at-enabled.org" (fictional) to specify that I am 
promising to provide useful metadata. So it is possible to place a seal of 
approval on a document.


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

I think that I have addressed that.



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

No I won't. I will point at sites that I know I can read. I will be 
disappointed that I can't read everything that my neighbour can read, but 
my life will have improved, if only slightly. And that's just me. Imagine 
how good a blind person will feel that he/she has access to an ever growing 
corpus of useful data.

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

Well, I understand that we could use links. But I also know from experience 
that authors are somewhat disinclined to make the effort to create an ever 
increasing number of files which need to be managed themselves, not to 
mention the task of managing the links.

I would be much happier to hear that HTML 5 would require that stylesheet 
and programming content had to be linked to the document rather than 
included in the HTML file. Moreover, I would like to option to disable 
fetching the programs so that my pages would arrive sooner and stop 
stealing cycles.

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

I don't agree with your conclusion. It is a logical leap that is unfounded.

As I have written, when a site publishes the fact that they are employing 
AT attributes properly and the community discovers that it is true, the 
users of that site will benefit. The fact that other sites do not will not 
prevent me from reading a site that does,

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

I would like to see them say that. I don't think that it's your place to 
speak for them.

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

Some people would say, and have said, that your own reasoning is flawed.

I agree that everyone should have a chance to make their case, and that an 
"expert" does not get to make pronouncements without presenting their 
arguments. I will note again that Alan Greenspan was not only considered to 
be a world-class expert, he also testified regularly before congress to 
present his arguments. But he was wrong. Not because he was irrational, but 
because he neglected evidence that was being presented by people who 
disagreed with his views. We, collectively, made a mistake by accepting his 
wisdom.

Today, I think that you are neglecting evidence, both technical and social, 
as pertains to various parts of the HTML 5 specification. I keep trying to 
figure out how to present the case in a new way so that you can see what is 
so obvious to me and others, but I haven't figured it out. I am a bit 
frustrated by this because I have been much more effective in previous 
incarnations of the HTML WG.

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

Actually, your suggestion to conflate caption and longdesc is entirely 
wrong from my perspective as a writer, typesetter and publisher. Regardless 
of potential benefits that may derive from including a long description of 
a picture in the caption, my first priorities would be for the caption to 
satisfy the editorial requirements of a caption. For the especial benefit 
of unsighted readers -- and possible spillover benefit to sighted readers 
-- I would also want to provide a long description of the picture if such 
were likely to aid comprehension. For example, under a photo of Ted Nelson 
receiving an award, I would include a caption like "Ted Nelson receiving 
award ... from ...", and a long description which might read "Photo shows 
Theodor Holm Nelson receiving the ... award from ... at the World Wide Web 
Conference in Brisbane, Australia. Mr Nelson is smiling and shaking hands 
with ... as he receives a multi-colored didjeridoo."

If I included all of that information in the caption, I would be breaking 
editorial rules for captions.

Moreover, assuming that the picture clearly shows that Mr Nelson is shaking 
hands and receiving a didjeridoo in front of a WWW banner, then sighted 
readers will derive no extra benefit from reading the long description.

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

These are not acceptable to me as an editor or manager of writers. It just 
makes my job harder.

Received on Monday, 29 June 2009 19:53:08 UTC