W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > October to December 2001

Re: Foundation for text techniques

From: Joe Clark <joeclark@contenu.nu>
Date: Fri, 7 Dec 2001 14:32:07 -0500
Message-Id: <a05100326b836c81cb8d0@[]>
To: WAI-GL <w3c-wai-gl@W3.org>
Cc: areed2@calstatela.edu
>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 

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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:59:22 UTC