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

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.

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


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


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


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

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.

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



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

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


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


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


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

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.


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

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Sunday, 28 June 2009 21:01:47 UTC