Re: some reflections on @alt usage

On Thu, 24 Apr 2008 00:13:36 +0200, Joshue O Connor  
<joshue.oconnor@cfit.ie> wrote:

> Al Gilman wrote:
>> * Cautions to the 'required is required' advocates:
>>  3. The HTML5 draft is attempting to provide markup for what has
>> in practice been a common case: insufficient human thought has
>> been applied to the web-posting of an image for there to be a
>> known-good @alt value for that image ... While there are downsides
>> to eliminating the simple statement "@alt is required," there are
>> upsides to the fact that the information provided to client-side
>> repair activity is of greater accuracy.
>
> Ok, but I guess you are suggesting that this will happen at the  
> author/validator level, as passing this information down the chain to  
> the end user will probably be pretty useless. If we look at the  
> authoring process as a chain and a flag or warning from a validator or  
> even a client side application that deals with graphical content, helps  
> the author(s) fix it, then fine.

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)

>> But don't underestimate the power of
>> running code.  If the author's tools flag @alt problems more
>> consistently; that replaces many many hours of lecture time in
>> the classroom, in terms of "good text alternates" that wind up
>> in the live Web.  It matters less what reference appears in the
>> footnote at the end of the discrepancy-explanation.  More that
>> the author gets alerted to the discrepancy more consistently.
>> HTML WG and HTML5 specification can help us
>> get there; do consider reasonable alternatives.
>
> I don't really follow. If I am parsing this correctly this comment seems  
> to say that the fact that a tool will flag an error or message about  
> missing @alt then this is a good way of educating people as to the  
> importance of @alt? And that this would not happen if the images have  
> @alt in the first place? This doesn't make sense to me.

I don't think that is what the comment says, but it is a large part of  
what I am saying and think it does make sense. Let me put it another way:

Today's (good) accessibility tools look for missing alt and say "you have  
a problem". They look for blank alt (alt="") and say 'make sure this image  
really is unnecessaryto understanding the content'. The best then also  
look for filenames and a few other identifiable things people use as  
defaults, by magic heuristics, and they say 'is there really nothing  
better you can say about this?'.

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.

>> ** longer, stream-of-unconsciousness mutterings
>>  +1 to "web pages where the page doesn't know what to say as the @alt
>> value are common."
>>  Note 1:  The language in the 22 January 2008 draft poisons the debate  
>> by talking only about "important" images where a suitable @alt value is  
>> not known.

Agreed.

>>> If the specification is going to state conditions
>>> under which the @alt attribute is to be omitted, they should be "I  
>>> don't know" conditions spanning both important and decorative (but
>>> unknown decorative) images as well.
>
> Ok but suggesting that there are conditions where the @alt can be  
> omitted is analogous to suggesting that there are circumstances where  
> its ok to upload blank graphics, or images with nothing in them (in  
> principle).

Well, that depends on the language. IMHO the specification should not say  
"It's OK to have no alt", but it should say "although no alt is bad, 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".

>> Note 2:  In particular, most accessibility experts will not agree that
>> the photo upload use case is one where the authoring tool could not
>> come up with something that is better than nothing.  So the example
>> adds more heat than light.
>>  Something on the order of
>>  $userScreenName's Nth photo [ uploaded | taken ] $date [ $time ]
>>  is something that uses information the generator of the HTML access
>> page for the uploaded image files has available and is arguably better
>> than nothing.
>>  -1 to "bad @alt is worse than no @alt in many situations"
>
> I agree.

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.

The example above is (while important to today's web) extremely specific  
to a class of content.

>> .. could not confirm this with the user community.
>>  +1 to "required @alt is persuasive in training sessions"
>>  Accessibility staff get limited time [...]

I don't actually find this terribly persuasive.

>> +1 to "Missing @alt cues repair, and this is useful."

If Missing @alt triggers a warning taht you need to repair then it can be  
valuable. This discussion really boils down to a need to understand why  
the guys at Flickr, My.Opera, Picasa, and some other representative 3rd  
parties made the particlar decisions they made in each case.

>> 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. (My stylesheet for opera does do  
this, and I was thinking of making a couple of varieties - one that  
removed all the things with no alt and another the things with alt='').

>> Note 4:  The Rorschach test example is also not a valid example of what
>> it attempts to illustrate....
>>  .. that there are appropriate things to say in a text alternate in this
>> case, and why not use @alt to say them?

Agreed.

Cheers

Chaals

-- 
Charles McCathieNevile  Opera Software, Standards Group
     je parle français -- hablo español -- jeg lærer norsk
http://my.opera.com/chaals   Try Opera 9.5: http://snapshot.opera.com

Received on Sunday, 27 April 2008 09:52:10 UTC