- From: David Poehlman <david.poehlman@handsontechnologeyes.com>
- Date: Sat, 3 May 2008 06:41:29 -0400
- To: "Henri Sivonen" <hsivonen@iki.fi>, "Julian Reschke" <julian.reschke@gmx.de>
- Cc: "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>
The bad as stated below comes down to choice. Well informed and authors who care and or are allowed or encouraged, payed to care and well designed tools can mittigate this as well as the validator. So, we are left then with: <mesage snip> 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) <end> The state we are in today has little to do with the requirement but much to do with the way it was implemented in terms of presentation. The only way I see around the bad other than continuing progress to decrease it through machining and education etc is to find a new attribute or even and element if you will that does one of two things. It either adds to the current set or replaces the thorn in such a way as to pre-empt the bad. It comes down at least in part to one thing. <tooltip> is good, although somewhat missplaced. alt used as <tooltip> is almost always a bad thing. No, I have no hard data, but I do know that many people I talk too seemed to think that they had to do something with that blank tooltip. One final note: Making alt a requirement for accessibility without providing for a means to accomplish the end e.g. making it valid and correct. does no one no good. ----- Original Message ----- From: "Henri Sivonen" <hsivonen@iki.fi> To: "Julian Reschke" <julian.reschke@gmx.de> Cc: "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> Sent: Saturday, May 03, 2008 5:37 AM Subject: Re: [html4all] HTML5 Alternative Text, and Authoring Tools 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). 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. 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. 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. -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Saturday, 3 May 2008 10:42:09 UTC