- From: Ian Hickson <ian@hixie.ch>
- Date: Sun, 28 Jun 2009 21:01:04 +0000 (UTC)
- To: Murray Maloney <murray@muzmo.com>
- Cc: public-html@w3.org
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