RE: test24 Text equivalents for APPLETs must be updated if APPLET changes

Jason White wrote:
 > I agree with John. Here's the problem: if an applet is accessible via
 > an API supported by my user agent, I won't need any "text
 > alternative", as the API satisfies my needs by allowing me to interact
 > with the user interface of the applet. For images and audio, however,
 > a text alternative is necessary.
 >
 > I propose that applet should not be considered as "non-text content".
 > The API requirements should be specified in 4.2 or, as John
 > astutely suggested, a new success criterion under 1.3. There is also a
 > requirement that if content can't be made accessible at all, (i.e.,
 > can't otherwise satisfy the guidelines), a more accessible alternative
 > should be offered. This is where text alternatives to applets can come
 > in as a last resort option where the API's aren't available or
 > adequate.


Because applets and other types of programmatic content often have 
comparable characteristics to other types of non-text content (e.g. 
provide function, provide information, provide decoration, etc.), I 
think that we need to be requiring that they be labeled. I'm not 
suggesting that an alternative be available that fully describes the 
programmatic content (this would be covered in 4.2), but a text 
alternative that labels/identifies an applet seems like an appropriate 
thing for us to be asking authors to do.

My understanding of UAAG on this subject is that users should have the 
ability to configure their user agents to turn off content that would be 
delivered via object, applet or script. While the expectation is that 
some information/functionality may be lost when these types of content 
are toggled off, if an author can expect that an end user may have 
turned these off, wouldn't excluding applets and other types of content 
from the need for a label entirely leave some users with no idea what 
they're missing?

In the end, the approach Jason describes above works, but I wonder if 
we're making it more complicated than is necessary...

example 1:

<a href="search.html"><img src="search.gif" alt=Search this site" /></a>

For the simple image above, an author simply needs to include a text 
alternative describing the function of the image.

The user, (whether they have images on turned on or off) has access to 
the alternative.

example 2:

<applet code="hover.class" width="135" height="53" codebase="css%20files/">
         <param name="color" value="#000080">
         <param name="hovercolor" value="#0000FF">
         <param name="textcolor" value="#FFFFFF">
         <param name="text" value="    ">
         <param name="effect" value="glow">
         <param name="image" valuetype="ref" value="art/searchbutton.gif">
         <param name="hoverimage" valuetype="ref" 
value="art/searchbutton_2.gif">
         <param name="url" valuetype="ref" value="indexes/search.htm">
       </applet>

By excluding applets from the definition of non-text content, it seems 
that we're suggesting that, for the applet above, an author would not 
need to include an alt attribute on applet as in example 1. Instead, 
he/she would need to determine whether there are UAAG conforming 
browsers that support an API that can be used to access this applet. If 
appropriate APIs  and user agent support exist, then no text alternative 
would be necessary. If they don't exist, the author would then have to 
provide an accessible alternative to the applet.

 From the user perspective, the code in example 2 above might cause them 
to be prompted to download a plugin or (in the absence of a text 
alternative) might cause the applet to be ignored completely. Without a 
text-alternative that identifies the purpose or function of the applet, 
he/she has no idea whether going to the trouble of downloading that 
plugin would be worthwhile. Further, if the end user choooses not to (or 
can not for some reason) download the plugin they end up having no idea 
what they're missing because the content has not been identified.

Both of the examples of non-text content above achieve the same result, 
but it seems to me that the results of an approach that doesn't at least 
require a brief description of function for programmatic content like 
this puts a much bigger load on both the author and the end user.

Thoughts?

-Ben

--
Ben Caldwell | <caldwell@trace.wisc.edu>
Trace Research and Development Center <http://trace.wisc.edu>

Received on Friday, 11 February 2005 15:43:30 UTC