- From: Ben Boyle <benjamins.boyle@gmail.com>
- Date: Sun, 13 Apr 2008 21:15:19 +1000
- To: "Henri Sivonen" <hsivonen@iki.fi>
- Cc: HTML4All <list@html4all.org>, "W3C WAI-XTECH" <wai-xtech@w3.org>, "HTML WG" <public-html@w3.org>
I think I understand this, but not sure. There is a difference between checking one's HTML syntax is valid, vs evaluating its accessibility (or any other value-based quality measure). You're advocating keeping these separate. I can see the gulf between the two. Where does "conformance" fit in on the scale? On Sun, Apr 13, 2008 at 6:55 PM, Henri Sivonen <hsivonen@iki.fi> wrote: > > 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 14:08:01 UTC