W3C home > Mailing lists > Public > www-archive@w3.org > September 2007

Re: [html4all] the alt attribute debate

From: Henri Sivonen <hsivonen@iki.fi>
Date: Tue, 25 Sep 2007 16:57:39 +0300
Message-Id: <6EA13EA1-2FCB-4B35-9DEC-D0E81D944667@iki.fi>
Cc: "advocate group" <list@html4all.org>, "John Foliot - WATS. ca" <foliot@wats.ca>, "Anne van Kesteren" <annevk@opera.com>, www-archive@w3.org
To: Steven Faulkner <faulkner.steve@gmail.com>

On Sep 25, 2007, at 14:35, Steven Faulkner wrote:

> >Yes, I have noticed that.
> so why have you continued to only talk about this point solely in  
> reference to JAWS?

Mainly because you have documented the usability bug in connection to  
JAWS specifically.

> >The point is that no one has so far explained why that behavior
> >(which is awful in some situations as you have demonstrated) would be
> >the permanent end state of development for AT and not just a
> >transient usability bug that is fixable in a handful of
> >implementations. For example, VoiceOver plus Safari on Mac OS X 10.4
> >do not share this usability bug, which trivially demonstrates that it
> >is possible to construct AT that doesn't have the usability bug.
> nobody has said that it is the permanent end state, of course it  
> would be easy to modify what is announced in response to a an image  
> without an alt in a particluar context.

Yet, I often get a feeling that arguments based on the current state  
of AT (JAWS in particular, sometimes WindowsEyes--everyone expects  
VoiceOver to be a moving target) have an implied premise that AT is  
what it is and as good as it gets. Sometimes it seems like the state  
of AT is taken as the most rigid piece in the overall Web ecosystem  
to the point of suggesting that browsers, authoring tools and  
countless authors change instead.

It has been explained to me why the AT upgrade cycle is slow. But it  
doesn't explain the general defeatist attitude towards AT R&D that I  
often sense in discussions.

There may be forces holding back Web client software changes, for  
example, existing content relying on a bug, major discontinuities in  
getting from here to there or the proposed change requiring the  
participation of competitors in lockstep. However, improving AT  
behavior with missing alt suffers from none of the usual constraints:  
an AT vendor could unilaterally improve it in its own product.

> The issue is not to do so much with what the AT UA can do with an  
> image without the alt attribute, it is about what the UA cannot do.
> It cannot reliably differentiate between an important image without  
> an alt attribute and an unimportant image. Therefore they generally  
> treat images without alt attributes the same way that they treat  
> images with alt="", that is they ignore them.
> The argument used to undermine this issue is that the UA can  
> perform heuristics to classify (critical content, spacer,  
> decorative, functional, representation of text etc) the images  
> without alt attributes and then decide what to announce based on  
> their classification. problem being I suggest is that there is no  
> reliable way to provide this classification.

The word "reliable" is the problem.

All too often in these accessibility debates it is taken as a given  
than someone else has to provide something reliable (or "unambiguous"  
or something like that). You don't get "reliable" from an  
uncooperative data source, which the Web is from the point of view of  
an AT UA.

With an uncooperative data source, the overall result is likely to be  
better if you shoot for "reliable enough" instead of refusing doing  
things that aren't totally reliable. With spam, for example,  
expecting the data source to become cooperative would be futile.  
Hence, people rely on measures that are reliable enough.

At least with alt text, unlike with spam, most uncooperative data  
sources aren't wanting to hurt you. They just aren't going to help  
you. It doesn't make sense to ask those who won't help you to hurt  
you if you have the option of asking them to neither help nor hurt.

>  So we come back to the point that not specifying anything for an  
> image is a worst case and will continue to be.

No, I don't think we have yet come to the conclusion that the absence  
of data will continue to be worse than bogus data. This should be  
trivially true: If a consumer prefer bogus data over absent data,  
bogus data can (by definition) be generated out of thin air. OTOH, if  
a consumer prefers absent data over bogus data, telling bogus and non- 
bogus data apart is harder.

> The only way I can see to identify images that are "critical  
> content" but the author cannot or will not specify an alt text for  
> them, is to provide a flag for this in the code,
> in this way it can be differentiated from the millions of images  
> out there of all different sorts that the authors simply did not  
> care to provide alts for.

AT UAs need to deal with those cases, too, though. The question is,  
really, whether explicit flagging as "critical" has enough value  
compared to falling in the same bucket with lack of alt for unknown  

> >(We shouldn't take stuff under /TR/ as holy writ set in stone when
> >following it clearly leads to worse usability than doing something
> >smarter.)
> who does?

Pointing to the /TR/ space looked more like a justification than a  
mere explanation. (And even as an explanation, it doesn't explain why  
the vendors have settled on something as bad.)

> >That's a good idea. However, I get a feeling that users may not have
> >a good grasp of what kind of ideas would be implementable and,
> >therefore, eligible to be suggested.
> what you are forgetting is that there are AT users who are also  
> programmers and designers and spec writers etc. who may be able to  
> grasp the complex possibilities that reside in a head such as your  
> own.

Of course. But saying "users" is generally understood as short-hand  
for end users--not developers who dogfood their products.

Henri Sivonen
Received on Tuesday, 25 September 2007 13:58:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:33:15 UTC