- From: Charles McCathieNevile <chaals@opera.com>
- Date: Tue, 11 Sep 2007 11:16:55 +0200
- To: "Henri Sivonen" <hsivonen@iki.fi>, "Steven Faulkner" <faulkner.steve@gmail.com>
- Cc: HTMLWG <public-html@w3.org>, wai-xtech@w3.org
On Tue, 11 Sep 2007 10:23:07 +0200, Henri Sivonen <hsivonen@iki.fi> wrote: > On Aug 29, 2007, at 21:48, Steven Faulkner wrote: > >> Investigating the proposed alt attribute recommendations in HTML 5 - >> http://www.paciellogroup.com/resources/articles/altinhtml5.html > > Great work. Thank you. Based on your testing, it is clear that the > current state of JAWS is so bad that indeed any generated placeholder > alt text (even the empty string) is better than omitting it. ... > When making Web pages today, catering to today's JAWS, which apparently > has unbearable placeholders, makes sense. It doesn't *necessarily* > follow, though, that writing the spec to *require* (as opposed to > *allow*) catering for the flaws of today's version of JAWS makes sense > considering the entire life span of the spec. I think the situation today is similar to that of seven years ago, where "we" were advocating for alt as a required attribute, but at the same time insisting, for accessibility reasons, that authoring tools don't just auto- generate it. This leads to a large amount of uselessness (which would have been the case anyway) and to some fraction of people doing the right thing. Plus it makes it easier to test... (If you cane tools that erroneously generate alt for validity, then you have half a chance that they won't be offered to people who would use that option rather than do something useful or just fail that requirement). > What, in your opinion, is the outlook on JAWS ever getting fixed? (By > "fixed" I mean to have image place holders that give a better user > experience than alt="" or alt="image" or page content duplication in the > case of a non-decorative image.) The problem doesn't really come down to JAWS, but to authoring tools/ environments. Flickr deciding to put null alt, or something that had the image's tags in it, would be a half step forward. Flickr, as a photo album, is an odd case - if you get a description then it generally makes sense not to have more text in an image. But where a CMS or athoring tool is used, it *should* have the ability to find out something about the image, or draw something only moderately bad, or propose the descriptions that have been used before. Without active participation from the author, all heuristics are pretty awful. > Should this WG expect that 7 years from now, the market leader in voice > browsing still hasn't evolved to have better heuristics to such extent > that J. Random Web app developer can do better by putting together > *some* generated alt text (even alt='', alt='image' or duplicating other > data already on the page)? I would expect more authoring systems to have developed the ability for J. Adminassistant to provide something half-useful when adding an image, and more authors to realise that they *can* do this easily enough and just remember. (10 years ago people literally argued that useful alt text as a requirement of *saying a page was accessible* was asking too much and should be abandoned. Sometimes progress is slow. cheers Chaals -- Charles McCathieNevile, Opera Software: Standards Group hablo español - je parle français - jeg lærer norsk chaals@opera.com http://snapshot.opera.com - Kestrel (9.5α1)
Received on Tuesday, 11 September 2007 09:17:21 UTC