- From: Murray Maloney <murray@muzmo.com>
- Date: Mon, 29 Jun 2009 15:45:10 -0500
- To: Ian Hickson <ian@hixie.ch>
- Cc: Murray Maloney <murray@muzmo.com>,public-html@w3.org
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