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

Jason wrote:
<blockquote>
Applets shouldn't be treated under guideline 1.1. They are not "non-text
content". If this isn't already on the issues list (and I haven't
conducted a search), it should be.

</blockquote>

Jason's correct.  A note to the definition of non-text content
explicitly excludes applets and other programmatic objects from the
definition of non-text content.  The definition and note read as
follows:

<blockquote cite="http://www.w3.org/TR/WCAG20/#non-text-contentdef">
non-text content includes but is not limited to images, text in raster
images, image map regions, animations (e.g., animated GIFs),
ASCII art,
images used as list bullets, spacers, graphical buttons, sounds (played
with or without user interaction), stand-alone audio files, audio tracks
of video,
and video. It also includes any
text
that can not be translated into Unicode.

Note:

Scripts, applets, and programmatic objects are not covered in this
definition and are addressed in
guideline 4.2.
</blockquote>

John


"Good design is accessible design." 
John Slatin, Ph.D.
Director, Accessibility Institute
University of Texas at Austin
FAC 248C
1 University Station G9600
Austin, TX 78712
ph 512-495-4288, f 512-495-4524
email jslatin@mail.utexas.edu
web http://www.utexas.edu/research/accessibility/


 



-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On
Behalf Of Jason White
Sent: Wednesday, February 09, 2005 1:31 am
To: Ken Kipnes
Cc: w3c-wai-gl@w3.org
Subject: Re: test24 Text equivalents for APPLETs must be updated if
APPLET changes



Ken Kipnes writes:
 > All,
 > 
 > Text equivalents for APPLETs must be updated if APPLET changes

Applets shouldn't be treated under guideline 1.1. They are not "non-text
content". If this isn't already on the issues list (and I haven't
conducted a search), it should be.

Any audio or image generated by an applet is non-text content, but the
applet itself isn't. One could argue that anything possessing
interactional behaviour is non-text content, but then, every form
control would count as non-text content, which is not a desirable
result. If the necessary API's are available, the user interface
provided by an applet can be highly accessible. Thus apart from the
question of what "non-text content" means, the guidelines should allow
for the circumstance in which the applet makes proper provision for its
own accessibility. I recognize this is in part a "user agent support"
issue, but this case will become increasingly the norm in the lifetime
of the guidelines.

Received on Wednesday, 9 February 2005 14:54:53 UTC