Re: Checkpoint on testability

William asked for a improved version of
quote
checkpoint x.3 When alternative versions of content are created, create 
them automatically when possible.
Example: A program that automatically converts text to images
endquote

here it is

checkpoint x.3.  When alternative versions of content are created, create 
the altenatives via automatic verifiable means.
Example: If images are text are offered, create images and alt text via a 
program, and provide means for testers to verify that the program works 
correctly.  For example, create the image and alt text via a server-side 
script (php, asp) that calls an image generator with a text string, and 
make the server-side script viewable to the tester (normally, users don't 
see the server side scripts; they only see the result of server operations 
theron).  Thus the tester can verify that the automatic means are indeed 
simply converting the input string to text and creating alt text that 
matches the string.

In other words, the spirit of this checkpoint is that conversions be done 
"in the open", by means subject to tester scrutiny, instead of behind 
closed doors.  Note that this does not require web sites to reveal all 
their source code.  For example, they would not have to reveal the source 
code of the image generator in the previous example.  However, they would 
have to allow the tester to check that it's working correctly.

I can see two objections to this requirement:

(a) They will require re-architecting if the code isn't sufficiently 
modular, e.g. if the transformations are scattered throughout a bunch of 
Perl code.   Could cost a buncha money, depending on how modular their code 
was in the first place.

(b) even if the code is modular, and the transformation rules are all 
nicely packaged and readable, a company may not want to reveal those rules, 
out of a quite understandable concern for their intellectual 
property.  People gotta eat, after all.

My answer to these is that they are valid concerns, but should be addressed 
in our discussion of compliance.  Our guidelines should simply address 
what's good for the users...and for the testers... which is also ultimately 
good for the users.  My understanding is that we are indeed postponing such 
matters to compliance, although I can't say that I see that in writing 
anywhere <unhappy-frown />.

Len
--
Leonard R. Kasday, Ph.D.
Institute on Disabilities/UAP and Dept. of Electrical Engineering at Temple 
University
(215) 204-2247 (voice)                 (800) 750-7428 (TTY)
http://astro.temple.edu/~kasday         mailto:kasday@acm.org

Chair, W3C Web Accessibility Initiative Evaluation and Repair Tools Group
http://www.w3.org/WAI/ER/IG/

The WAVE web page accessibility evaluation assistant: 
http://www.temple.edu/inst_disabilities/piat/wave/

Received on Friday, 22 December 2000 12:02:02 UTC