Re: Foundation for text techniques

>Constraint: In common ("visual") browsers, the presentation of the 
>ALT text normally uses the same real-estate that would contain, if 
>the user chose to load images, the corresponding visual. To maximize 
>the likelihood of fitting in the reserved area, the ALT text should 
>be as brief as possible.

Well, this is really a reaction to broken implementation in browsers, 
though admittedly I do not know how to handle every combination of 
bounding-box size, alt-text length, and font choices.

My own advice (copied from somewhere else, I forget where) is to 
limit alts to 1K in length.

>In visual browsers, the TITLE text is normally available as a "tool 
>tip", that is, as text which pops up when the mouse cursor is 
>positioned over the element area, regardless of whether the element 
>area contains the default element or its ALT text.

Or in status-line displays (iCab) or on special screens (titles on 
links only in Lynx).

>In non-visual (text, auditory etc) browsers, the presentation of the 
>TITLE text may depend on whether an ALT text string is also 
>available. Such browsers may present the TITLE text automatically if 
>ALT is not found. If ALT text is available, the presentation of 
>TITLE text depends on a user-set option, or on user input. Users of 
>text browsers generally prefer that if ALT and TITLE are both 
>displayed, the TITLE be presented in parentheses after the ALT. (I'd 
>like input from list users on what is preferred by users of auditory 
>and other browsers.)

This again is broken device behaviour. alt and title must both be 
available to the user if present. (In a graphical browser where the 
image actually successfully loads, alt should not be available.)

>4. LONGDESC is a separate resource which provides, for users unable 
>to access the visual in full detail, all the information that a user 
>to whom the visual is fully accessible would be able to extract from 
>it if she examined the visual exhaustively.

Let's be very careful about saying "all."

>  It should be usable not only by users who require ALT, but also by 
>users who can extract casually adequate information but not complete 
>detail from the visual itself. For example, a colored image might 
>convey information equivalent to an adequate ALT even to a 
>color-blind user, but this user then might use the LONGDESC resource 
>for access to details that others could deduce from colors in the 
>image.

No one using actual longdescs (not that there are many of them) 
explains every colour of every object. How do you do that with a 
photograph? How about a set of 50 photographs?

Also, there is a consistent misunderstanding of colourblindness. The 
fact that a specific colour is seen as something different by a 
colourblind person is neither here nor there in accessibility. The 
issue is *confusing* the object with that colour with something else. 
I suppose a photograph of a traffic light would be an example of 
this, but such examples are rare if not contrived.

>>In Internet Explorer, when images are presneted, the alt-text is 
>>also available as a tool-tip.

Such behaviour is counter to the spec and should be discouraged. I 
think they fixed it in Windows IE 5 and later anyway. Netscape 4 
remains broken in an unending list of ways.

>Netscape Navigator 4 had the same behaviour, Mozilla (last time I checked
>0.9.5) completely hides the ALT information if the image is displayed -
>this is certainly a bug in Mozilla,

This is certainly the *correct* behaviour in *all* visual browsers. 
alt is an *alternative*. Just as summary on table should never be 
presented visually, alt should never be presented visually if the img 
or area is actually present.

-- 
   Joe Clark | joeclark@joeclark.org | <http://joeclark.org/access/>
   Accessibility articles, resources, and critiques

Received on Friday, 7 December 2001 14:33:17 UTC