RE: [Techs] Short text alternatives for object element

Joe Clark wrote:
<blockquote>
The spec states:

<http://www.w3.org/TR/REC-html40/struct/objects.html#edef-OBJECT#idx-obj
ect-3>
>>A user agent must interpret an [244]OBJECT element according to the
>>following precedence rules:
>>
>>1. The user agent must first try to render the object. It should not 
>>render the element's contents, but it must examine them in case the 
>>element contains any direct children that are [245]PARAM elements (see

>>[246]object initialization) or [247]MAP elements (see [248]client-side

>>image maps).

Note the following:

>>2. If the user agent is not able to render the object for whatever 
>>reason (configured not to, lack of resources, wrong architecture, 
>>etc.), it must try to render its contents.

If it *can't* render the object, it *must try* to render its 
contents. User agents are not permitted to render multiple objects at 
once.

Also:

>>If a user agent cannot render the outermost [257]OBJECT, it tries
>>to render the contents, which may be another [258]OBJECT element, 
>>etc.
>>
>>[...]
>>
>>[In an example given]
>>The outermost declaration specifies an applet that requires no data
>>or initial values. The second declaration specifies an MPEG 
>>animation and, since it does not define the location of an 
>>implementation to handle MPEG, relies on the user agent to handle 
>>the animation. We also set the type attribute so that a user agent 
>>that knows it cannot render MPEG will not bother to retrieve 
>>"TheEarth.mpeg" from the network. The third declaration specifies 
>>the location of a GIF file and furnishes alternate text in case all 
>>other mechanisms fail.
</blockquote>

John replies:
Thanks for providing the exact language from the specification, Joe.
This confirms the point I was trying so clumsily to make:

If (1) the <object> element is used according to the specification, and
(2) the browser is capable of rendering the content specified in the
data attribute, then (3) a text alternative in the body of the <object>
element will not be rendered by the user agent.   Therefore, (4) text
alternatives provided in this manner (as recommended by Technique 10.5
in HTML Techniques for WCAG 2.0) will often be useless as an aid to
accessibility

People who need the text alternative need it even when (perhaps
especially when) the browser correctly renders non-text content.  That's
true for people using screen readers, who need the screen reader to
speak the text alternatives associated with images; and for people who
are Deaf or hard of hearing, who may not use assistive technology but
who need text transcripts of spoken-word audio.    If the URI for an
image is given as the value of the data attribute, browsers such as IE,
Mozilla, and Opera will display the image; screen readers, however, will
not read any text alternative provided in the body of the <object>
element, because the image takes precedence.  Similarly, if the data
attribute points to an audio recording and a plug-in capable of playing
that recording (Real One, Quicktime, Windows Media Player, etc.) is
present on the user's system, the audio will play and the browser will
not display a text transcript provided in the body of the <object>
element. A user who is blind will not be aware that non-text content is
present; a user who is Deaf or hard of hearing may get some visual
indication that a plug-in is playing something but will not be able to
perceive the non-text content in a useful way. 

Maybe it's just what Joe calls my longstanding confusion about
alternatives, but it seems to me that the recommended technique fails to
satisfy the requirements of Guideline 1.1.

If a text alternatives falls in the woods ...

John

Received on Wednesday, 18 August 2004 21:06:46 UTC