- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Sun, 4 May 2008 00:31:05 +0300
- To: Al Gilman <Alfred.S.Gilman@IEEE.org>
- Cc: Julian Reschke <julian.reschke@gmx.de>, James Graham <jg307@cam.ac.uk>, Steven Faulkner <faulkner.steve@gmail.com>, Ian Hickson <ian@hixie.ch>, John Foliot <foliot@wats.ca>, HTML4All <list@html4all.org>, public-html@w3.org, W3C WAI-XTECH <wai-xtech@w3.org>
On May 3, 2008, at 22:43 , Al Gilman wrote: > On 3 May 2008, at 5:37 AM, Henri Sivonen wrote: > >> On May 2, 2008, at 17:42 , Julian Reschke wrote: >> >>> In doubt, the default should be not to change HTML4. >> >> >> FWIW, I have a different view of what to do when in doubt: >> >> When in doubt, do what doesn't cause harm. >> >> I think experience (yes, not written down quantitatively) with >> HTML4 validation shows that casting an *accessibility* requirement >> into a simplistic presence/absence *syntax* requirement does both >> good (reminds some people to provide useful alt who somehow >> wouldn't otherwise) and harm (induces people to pollute non- >> graphical presentation with duplicate data, useless data like >> "image" or make the context less understandable by concealing the >> presence of images). > > Can you take the following re-statements as a 'yes'? > >> Syntactic presence of @alt on <img> is not a sufficient technique >> for meeting >> WCAG 2.0 Success Criterion 1.1.1. > > >> Approximating the accessibility requirements for a text alternate >> with a syntactic >> requirement for @alt to be present can lead to erroneous practice. I think I agree with those statements. An aside on the topic of WCAG 2.0 (not a response to what you said): With WCAG 2.0 the W3C offers a notion of conformance on the accessibility evaluation axis. I'm curious why accessibility advocates want to bake some of that into the notion of conformance on the axis of machine-checkable HTML5 syntax instead of promoting conformance on the accessibility evaluation axis on its own right. So far, I've come up with two possible explanations: 1) It's about assuming that a notion of "Valid HTML5" is more appealing/marketable than a notion of "A[A][A] level conformance to WCAG 2.0". If this is it and such assumption were correct, wouldn't it mean that there'd be people who'd seek to satisfy a validator without necessarily doing good to accessibility in the process (and, therefore, we should be careful to avoid inducing that kind of behavior)? 2) The notion that a document could be deemed "correct" on *some* evaluation axis without *also* being accessible is somehow offensive. If this is it, I think it isn't productive to deny non-accessibility evaluation axes to use cases that aren't accessible to everyone, since there are legitimate use cases in the universe of possible Web pages that aren't accessible to everyone. For example, the Image Report feature of Validator.nu is by its very nature itself not accessible to a person who can't compare images and text. Is either of these on the mark or is there something else that I'm not realizing? >> I believe the current design in HTML 5 and Validator.nu's Image >> Report feature will pretty much remove the bad effects of requiring >> alt for validation. > > Two ideas: > > 1) Are you suggesting that HTML5 adopt some sort of a requirement or > other > endorsement of Validator.nu's Image Report feature? I'm not suggesting that. I am, however, suggesting that having the feature in the market-leading HTML5 validator should alleviate the concern that not making alt presence a machine-checkable *syntax* requirement somehow made the *accessibility* issue lose prominence. In fact, Validator.nu gives the alt issue more prominence than HTML 4 validators ever have. As a matter of *principle*, I think HTML 5 shouldn't *require* HTML5 validators to have particular additional features in addition to the HTML 5 validation function (i.e. deciding if the input meet machine- checkable syntax requirements), since the additional features beyond strict interoperability of the validation function should be an area where implementations are allowed to innovate and compete. As a practical matter, though, I wouldn't object to HTML 5 requiring or recommending HTML5 validators to have features that I've already implemented. Also, I wouldn't object to accessibility advocates objecting to any product or service that tried to compete with Validator.nu without having a similar feature. :-) > This is expressly > excluded from the job of a conformance checker in the current TR draft > of HTML5. > > http://www.w3.org/TR/html5/#conformance Indeed, in Validator.nu, the Image Report is not part of the HTML5 validation function. The outcome of the validation function is computable. The Image Report doesn't give a computed yay or nay. Instead, it presents information to help a human make assessments. > 2) It would seem to me that the value added by Validator.nu's Image > Report > feature is insensitive to whether @alt is required or not required. > It reduces the criticality of the question, but does not bias the > answer > one way or the other. I think it is sensitive to the issue. As a practical matter, at this point the market-leading HTML5 validator is addressing the *accessibility* issue, so the need to make it into a *syntax* issue is greatly reduced if not completely removed. Compared to making it into a syntax issue, the UI of the Image Report is carefully designed to avoid the downsides of making it a syntax issue: The Image Report always lists *all* <img> elements of the input page. There is no way to make the list shorter (without removing images). This means that there's no bogus value that an author could include in order to make the report look shorter/cleaner. I don't want to even add warnings to the *syntax* check report, because it would reintroduce the problem of authors seeking to make the report look shorter by including bogus data. >> Thus, if we consider some kind of indifferent zero level of >> aggregate goodness/badness, it removes the negative side, so other >> things can only leave the aggregate positive or to the zero level. >> >> In all likelihood, it will also lop off *some* of the good effects. >> Still, it seems totally implausible that people who provide alt >> because they care about accessibility would suddenly stop if it >> weren't a machine-checkable *syntax* requirement. Hence, it seems >> plausible that the aggregate effect will remain on the positive side. > > You are leaving out the authors who don't care about accessibility > before > they are nagged, but yet do the right thing when nagged. > > Not everyone who discovers @alt via a conformance check stuffs > garbage in the > attribute. That's what I was referring to when I said "In all likelihood, it will also lop off *some* of the good effects." To mitigate the problem of lopping off some good effects, Validator.nu gives the alt issue more prominence than HTML 4 validators ever have: The HTML5 facet of Validator.nu gives one third of its UI input real estate to the image report feature (one out of three changeable input widgets) and the report about alt values is way more thorough than just flagging absence. >> Taking a course of action that has both good and bad effects on top >> of a net-positive aggregate baseline means seeking to do some good >> while accepting collateral damage of the bad side. I think a course >> of action with collateral damage should be based on data about the >> aggregate delta effect of the course of action remaining positive. >> >> We don't have data about that, so defaulting to removing the >> negative side without knowing the magnitude of either makes sense. > > Except that your argument that we are removing only negative is > debatable, > not prima_facie convincing. I am not putting forward an argument claiming to remove only the negative. ("In all likelihood, it will also lop off *some* of the good effects.") I am putting forward an argument that the net effect will be on the positive side even if we don't seek to gain some unknown magnitude of incremental positiveness in a way that is known to incur an unknown magnitude of collateral negativeness. > What seems to be broadly agreeable is that Validator.nu's Image > Report adds significant > value to the authoring process. But the HTML5 draft currently > disowns this value. I think the practical value isn't removed even if HTML 5 "disowns" it, but I'd be OK with the spec acknowledging it. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Saturday, 3 May 2008 21:31:53 UTC