W3C home > Mailing lists > Public > public-html@w3.org > September 2007

Re: Investigating the proposed alt attribute recommendations in HTML 5

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
Message-ID: <op.tyhf2hu4wxe0ny@widsith.lan>

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  

> 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.



   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:14 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:26 UTC