- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Sun, 13 Apr 2008 11:55:05 +0300
- To: HTML4All <list@html4all.org>, W3C WAI-XTECH <wai-xtech@w3.org>, HTML WG <public-html@w3.org>
First, why do I even care to touch this rathole topic? It affects directly how the product I develop is expected to behave, and that affects its relationship with its users. Here's how I see this discussion: There is no law of physics or a fundamental result of computer science that prevented computers from pushing pixels around without pushing around a string at the same time. One group of people (the html4all folks) makes a value judgement that people using computers should make computers push around a string when they push around pixels in order to benefit a second group of people (the blind). A third group of people will make a value judgement that pushing pixels around without a string is valuable as such and they don't provide the string as having to provide a string as well would effectively make their use case infeasible (for example, people with camera phones with one- button photo taking and immediate uploading to a photo hosting service). A fourth group of people (developers of photo hosting services) will write software that the third group of people will use. This fourth group--not the third group--are potential users of software I develop: an HTML5 validator. A part of this fourth group consists of software engineers who will 1) write software that is primarily meant for pushing pixels onto the Web (no matter how you try to spin it, in the real world, pushing the pixels to the Web is the primary function--getting the alt text out there is not the primary function) 2) want (either directly themselves or as a client requirement) the output of their software to be valid HTML (whatever that means) 3) realize that there's no fundamental computer science barrier to pushing around pixels without an accompanying string (hence the string can be faked to accomplish #1 and #2 simultaneously) The first group of people wants, based on their value judgment, to establish a social norm onto the third group of people against the value judgment of this third group. This is a social problem. The norm is supposed to benefit the second group of people: the blind. Thus, any rational measure of the goodness of the policy should involve measuring the actual benefit to this second group. Now, does the first group take their social norm directly to the people whose behavior they want to modify? No. Instead, they want to masquerade the social norm as a technical norm, to use the PFWG as a proxy that tells the HTML WG what to do, so that the HTML WG may use the HTML 5 spec as a proxy for influencing the behavior HTML5 validators, so that HTML5 validators are turned into vehicles of advocacy against the fourth group (developers) in the hope that they turn their products into vehicles of advocacy that finally reach the people that the first group wants to impose their social norm on. I think that in this process, the relationship between the product I develop and its users is harmed, because the product then is no longer a tool working for its users but a vehicle of advocacy for someone else. This is one reason why I care. Furthermore, I think complaining about missing alt to developers whose software *simply doesn't have that data* because the third group of people didn't provide it causes developers to either ignore the validator (not what I want) or faking the data they don't have (bad for the supposed beneficiaries of the policy). I even agree that it would be nice if all photos had alternative text. But I don't think it is realistic, and I don't want to internalize the fallout that the first group externalizes by making the product I develop part of a long proxy chain instead of taking their issue directly to the people they want to influence (the people with camera phones in this example). Now, does the policy benefit the intended beneficiaries? It is clear that the policy will lead to information loss or bogus information in a non-trivial proportion of cases. This means that user agents have less information to work with to benefit users. The harm part is obvious on the surface given what we know about the consequences of faking data when it is missing instead of signaling that it is missing. (Consider the examples Julian gave: http://lists.w3.org/Archives/Public/public-html/2008Apr/0314.html ) If the harm in this case defies the obvious, I think the obvious needs to be proven wrong by research. Furthermore, the alleged benefits of the policy are speculative--that the policy of requiring alt syntactically would make more people supply useful alt text than telling people that a good alt text is needed for accessibility. With the harm side obvious and the benefit side speculative, I think the policy shouldn't be adopted without empirical research showing that the benefit exceeds the harm as perceived by the supposed beneficiaries. If research shows that there indeed would be a net benefit for the blind, then we can weigh if that net benefit is so great that it justifies collateral damage (e.g. turning some potential users away from validators). As for "sending a strong message" while actually not benefitting the supposed beneficiaries, I have no interest in becoming (through the product I develop) a stooge for such a policy. This is another reason I care. Sending a strong message doesn't necessarily translate into better accessibility. Consider: http://www.nytimes.com/2008/01/20/magazine/20wwln-freak-t.html?_r=1&ex=1358485200&en=0d05099c03c97375&ei=5090&partner=rssuserland&emc=rss&pagewanted=all&oref=slogin On Apr 11, 2008, at 13:08, Charles McCathieNevile wrote: > On Fri, 11 Apr 2008 11:29:20 +0200, Henri Sivonen <hsivonen@iki.fi> > wrote: >> Saying that such products should be >> programmed to output invalid HTML isn't a viable answer, either. > > Why not? Almost *every* tool I know of that produces HTML produces > invalid > HTML, so I am not sure how you determine that there is some > existential > reason why this cannot happen. We are talking about defining what's valid. The validity definition doesn't matter for people who don't even want the tools they write to output valid HTML. Therefore, it is only relevant to consider people who might care about the validity of the output of their products. On Apr 11, 2008, at 15:05, Steven Faulkner wrote: > Two images without explicitly associated text alternatives. > 1 is an image is decorative that the author has accidently left off > the alt, the other is "critical content" that the author could not > provide an alt for whatever reason > 1 can be safely ignored, the other should be brought to the attention > of the user. > > <img src="abc.jpg"> > > <img src="xyz.jpg"> > > How is Assistive Technology supposed to reliably determine this? > Given that these two images could be the same, but their meaning > differ widely depending on the intent of the author in regards to > their use. That question is a red herring. The right question is: What do you expect a content management system to do when its user uploaded an image but did not provide alternative text? And the follow-up: How is your answer better that letting the CMS signal to the UA that it doesn't have alternative text? (The simplest definition for such signaling is the omission of the alt attribute.) On Apr 11, 2008, at 20:34, Dave Singer wrote: > I gave an anecdote before about an installer program that insisted > on text strings to describe optional installs. Many, many packages > came configured offering, say "the frotz option" and if I asked for > the "alt" I would get the text "this installs the frotz option". If > the installer *knew* that there was no explanation, it might be able > to say "this installs a background process with root privilege, and > a plug-in to the mail program" and I might be a little more informed. Indeed. A software developer with an output spec and insufficient input where the input can satisfy the main objective of his/her software *will* fake the missing data to match the output spec as far a computer can tell. That's how software developers behave. Here's my earlier example: "For example, if you are a kernel developer and you are copying files from a file system that doesn't record the creation dates of files to another file system that insists that every file *must* have a creation date, you don't tell your boss/customers/whatever that you can't copy the files. Instead, you fake the creation date (the current time from the clock, the start of the epoch, whatever)." > Similarly, a web agent given an image with no alt might be able to > indicate the size of the picture, and there is plenty of evidence to > suggest that in time it could do image analysis and work out that > there is a person, it's a landscape, and so on. If the alt text is > provided but worthless, it would obscure this capability. Indeed. On Apr 11, 2008, at 23:07, Matt Morgan-May wrote: > We know from over 10 years of experience that authors are going to > lie. Does inducing authors to lie benefit the stated beneficiaries of your policy? > You cannot turn one of the most common validity and accessibility > failures > on its head simply because an empty alt attribute is unattractive. The empty string as the value and the absence of the attribute signal different things. Making both cases the same is information loss. On Apr 11, 2008, at 23:15, John Foliot wrote: > I need > only quote one of the HTML5 Working Groups' personal blogs to > illustrate > this fear: > > "I am currently following HTML5 (omitting alt) as it wasn't really > clear to me what would be a better solution given the single > constrain I > have: not finding it necessary to provide replacement text for all > those > images." (http://annevankesteren.nl/2007/09/alt) - Here Anne did not > "find > it necessary" - not that he could not, nor that the image was an Ink > blot > test that providing alternative text to would invalidate (the two > scenarios > suggested in the draft spec), but simply that he did not find it > necessary. > The fear is very real! Suppose Anne hadn't written his CMS himself and I'm selling Anne a CMS that I develop. What should I program the system to do when Anne doesn't supply alternative text? (Also suppose that I still want to extract a licensing or consulting fee from him.) > Henri Sivonen wrote: >> A piece of software gets images from somewhere and puts them >> automatically out on the Web. What should the developer of that piece >> of software program it to do when an image arrives from whatever pipe >> they arrive from without alternative text? How do you require a >> program to emit something it simply doesn't have without faking it >> with junk? > > If sewage passes through a conduit, should the conduit do nothing, > or at the > very least attempt to filter out the larger pieces of sewage? What incentive does the developer of the conduit have to block what you call sewage? Is that incentive stronger than whatever incentive there is to let the "sewage" pass through? > Henri S. used the word "fake", but that is undefined. This once again > points to the need (IMHO) for one or more reserved values that user > agents > can "standardize" on (remember, this *IS* about standards) that > address > possible scenarios when content authors fail to, or cannot, provide > appropriate alternative text. "_notsupplied" How is alt='_notsupplied' better than defining the absence of the attribute to mean exactly what you would define alt='_notsupplied' to mean? > and "_decorative" are two that > instantly come to mind. How is alt='_decorative' better than defining alt='' to mean exactly what you would define alt='_decorative' to mean? > "_notsupplied" has the added benefit > (IMHO) of also applying a subtle but real social pressure on content > contributors to do something, but if they choose to ignore that > pressure, > then the default of "_notsupplied" still allows compliancy, whilst > still > retaining the mandated need for alt values for all non-textual > content. Ah. This is how it is supposed to be better. Thus you want someone other than you to apply the pressure to someone other than whom you seek to apply the pressure to. And you want to do it by making the syntax cruftier. Frankly, I think you are now at the point where you are vehemently clinging onto a bad policy and amending it with worse and worse additional rules in order to avoid re-examining whether the need of the amendments should be taken as an indication that the base policy needs adjustment. I don't know a name for this phenomenon, but others shouldn't play along to save you from re-examining the policy. On Apr 11, 2008, at 23:18, Bonner, Matt (IPG) wrote: > Are there any usability studies or tests done by screen > reader software companies that could help resolve this > debate? Excellent point! On Apr 11, 2008, at 23:54, Katie Haritos-Shea wrote: > People will continue to commit crimes and break the law........but > it that a reason not to have them? First, HTML 5 is not law, and I don't want an HTML5 validator to have anything to do with legal proceedings. As for making laws that people break, it is corrosive (to use Lessig's vocabulary) to society to have laws that normal people are in violation of in their daily lives. This is why prohibition and laws like the DMCA/EUCD are bad as they turn normal people into law- breakers and makes them really cynical about law in general thereby devaluing laws in general. Likewise, a validity rule that normal Web developers would game in their daily development activities devalues validator messages. On Apr 12, 2008, at 01:24, Matt Morgan-May wrote: > If you allow alt to become optional in order to satisfy user-uploaded > content requirements, then accessibility evaluation and repair tools > have no > way of knowing whether you omitted it purposely, or out of ignorance. We are talking about what HTML5 validators are to say. We aren't talking about accessibility evaluation tools. WCAG is free to be normative about those. However, I think accessibility evaluation tools make people write for the tools instead writing for accessibility. That's why accessibility should be evaluated by people. An HTML5 validator isn't an accessibility evaluation tool--or at least I think it shouldn't be. An HTML5 validator is just a spell checker for the benefit of markup writers so that they can identify typos and typo-like mistakes instead of having to figure out why a counter- intuitive error handling mechanism kicks in when they test in browsers. A spell checker doesn't tell you if your fiction writing is entertaining or non-fiction actually factual. Those are different evaluation axes. > You can define the exception case that warrants a missing alt > attribute as > narrowly as you like in the spec, but you know as well as I do that > people > aren't going to read the spec for guidance at that level, if they > read it at > all. FWIW, Validator.nu doesn't flag PUA characters as errors even though they are prohibited most of the time, since there's also a narrow legitimate use. It does give a one-time warning, though. > Further, I think that while user-generated content is a popular > category of > web content, it's just one such category, and since there are any > number of > other kinds of content for which no such exception should exist, > there's no > justification to turn the rules around on alt solely for the benefit > of > those sites. The syntax rules need to be lax enough for all kinds of sites to be able to comply. If all sites can't be accessible, too, then accessibility and syntactic correctness are different evaluation axes. On Apr 13, 2008, at 03:35, Leif Halvard Silli wrote: > In this regard, I proposed [1] - as an replacement for the current > "WYSIWYG made" stamp - a new "unready" stamp, which all authors - > couples, and blind - and all editing tools - could use, when they > need to offer HTML which they consider technically unready. Alternatively, we could call "unready" valid HTML5 and "better than unready" valid HTML5 with WCAG compliance. We don't have to conflate accessibility evaluation with the syntactic correctness. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Sunday, 13 April 2008 08:55:51 UTC