Possible SC about functionality for 1.3 (was RE: test24 Text equivalents for APPLETs must be updated if APPLET changes)

As I noted yesterday, Guideline 1.3 currently requires developers to ensure that information, functionality, and structure are separable from presentation.  Currently, however, there are no success criteria related to functionality.

It's possible that adding a success criterion about functionality under 1.3 would help us resolve questions about whether and how to divide issues about scripts, applets, and programmatic objects between 1.1 (which seems like a bad idea) and 4.2 (which somehow seems not quite right either).


As a way to start off discussion, here is what strikes me as the most relevant provision under the US Section 508 standards for Software Applications and Operating Systems (1194.21).  Note that this is *not* from the 508 standards for Web-based Information and Applications.
<blockquote cite="http://www.section508.gov/index.cfm?FuseAction=Content&ID=12#Software">
(d) Sufficient information about a user interface element including the identity, operation and state of the element shall be available to assistive technology.
</blockquote>

And here is what the Section 508 standards for Web-based Information and Applications has to say about applets, etc:

<blockquote cite="http://www.section508.gov/index.cfm?FuseAction=Content&ID=12#Web">
(m) When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide
a link to a plug-in or applet that complies with §1194.21(a) through (l).
</blockquote>I am *not* proposing that we adopt this language. I'm suggesting that we consider adding a success criterion on functinality under Guideline 1.3 to see if that solves some problems for us.

John
Here is where the Section 508 Web standards incorporate the Section 508 software standards by reference...


"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: Jason White [mailto:jasonw@ariel.its.unimelb.edu.au] 
Sent: Wednesday, February 09, 2005 5:34 pm
To: John M Slatin
Cc: caldwell@trace.wisc.edu; Chris Ridpath; Ken Kipnes; w3c-wai-gl@w3.org
Subject: RE: test24 Text equivalents for APPLETs must be updated if APPLET changes


John M Slatin writes:
 > Ben Caldwell wrote:
 > <blockquote>
 > I think we should consider modifying our definition of non-text content 
 > to include scripts and other programmatic objects as *functional* 
 > non-text content.
 > 
 > That way, guideline 1.1, level 1, success criterion 1 would require a 
 > text alternative that describes the purpose of function of programmatic 
 > objects and guideline 4.2 would address the need to either make that 
 > programmatic content directly accessible to provide an accessible 
 > alternative.
 > </blockquote>
 > 
 > I'm not sure it's a good idea to define scripts, applets, etc., as  > non-text content.

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.

Received on Thursday, 10 February 2005 16:15:29 UTC