Re: some reflections on @alt usage

Charles McCathieNevile wrote:
> The idea behind making @alt optional is that having a *validator* 
> warning ahs meant that tool makers above the author in the chain are 
> putting destructively bad alt in, rather than failing validity. (Where 
> "destructively bad" means that it does more harm than good - see below)
[...]

>  > an alt that is made up for a default, especially generic labels like 
'photo' or a null value, is generally far worse,
>so ommittng the alt attribute is the lesser of two evils". 

Agreed.

> The most basic test is "is there an alt attribute"? Every "generic" 
> accessibility tool I have ever heard of checks that. If you just put 
> *something* in, then the most fundamental test becomes useless.

Also agreed.

> I think this needs to be more nuanced. Poorly authored alt is better 
> than nothing. But some stock phrase shoved in willy-nilly is not.

It could also be argued that most @alt text is actually poorly authored 
anyway.

>>> Present client-side processing is centered around the following pattern:
>>> if @alt="" the image is ignored.  if @alt is not there, processors may
>>> and sometime do attempt some sort of repair.  The filename of the image
>>> is commonly used as a substitute.
>>
>> Yes, and these heuristics need to be improved and modified. For example, if through some kind of UA preferences a screen reader user could choose to /not/ trigger heuristic evaluation when an image with no @alt is given focus then this could be a good thing for end users.
> 
> I was under the impression that the user *can* do this, although it depends on the software they are using. 

and also their level of knowledge etc. I am suggesting making user 
interaction as easy as possible in particular for non technical users 
(i.e most people) so they don't really have to fiddle about with 
preferences or settings. This is largely to down to vendors and good 
product design.

Cheers

Josh

Received on Sunday, 27 April 2008 11:42:11 UTC