RE: programatically determineds

Here's another attempt at a definition for "programmatically
determined." I'm not sure if it works-- but I *am* sure that someone out
there will let us know if it doesn't!! <grin>

<proposed>
Programmatically determined
Recognized by user agents (including assistive technology) through the
use of a publicly documented markup or programming language, data
format, protocol, or API.
</proposed>

The part about "markup or programming language, data format, protocol,
or API" comes from our definition of "technology" in the WCAG 2.0
Glossary (I changed the order a little, but the words are the same).



I *think* this would work even for the scenarios Alex was talking about
on this week's call, where the vendor creates proprietary content that
requires a proprietary UA (such as a plug-in). Content that required a
proprietary user agent (such as a plug-in) could still pass if the
plug-in supported the relevant accessibility API (such as MSAA or the
Java Accessibility API, etc.).

I'm aware that this doesn't "solve" the Longdesc Problem-- i.e., if
content uses an accessibility feature that no user agent supports ,
should a conformance claim be allowed?

But I *think* this is covered by baseline. Baseline is defined in our
Glossary as a "Set of technologies assumed to be supported by, and
enabled in, user agents in order for Web content to conform to these
guidelines."

Content that uses technologies in the declared baseline can't claim
cnoformance unless it meets at least all L1 success criteria. Content
that uses technologies outside the baseline is covered by GL 4.2.

Is there a hole somewhere? (Please drive a truck through it so I can
hear it<grin>).

John
"

Dr. John M. Slatin, Director 
Accessibility Institute
University of Texas at Austin 
FAC 248C 
1 University Station G9600 
Austin, TX 78712 
ph 512-495-4288, fax 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 Kerstin Goldsmith
Sent: Friday, January 06, 2006 12:24 PM
To: wcag
Subject: programatically determineds



Hi,

Instead of raising my hand yesterday to make the discussion on 
"programatically determined" longer, I have opted to try to put some 
thoughts into email. 

My concerns with tying "sufficient techniques" to actual AT that can 
"find/render" content is the same concern I, and others, had in Dublin 
oh so long ago.  We have no guidelines for AT that we can use to ensure 
interoperability, just as we were concerned back then about putting the 
onus on the content developers to work around User Agent failings.  What

if AT should "reasonably" be expected to "find/render" a certain kind of

content, but to date does not -- that shouldn't mean that the content 
developer has not met the requirements.  Again, I think it is extremely 
dangerous to tie compliance to outside technologies, like UA or AT.  
It's not fair to the content developer, and I really don't believe that 
it is within the scope of our job.  Tracking all the changes in AT will 
be burdensome, too.  Pushing AT to "do the right" thing by supporting 
coding that is "reasonable" -- widely accepted/rendered by at least one 
form of UA -- will naturally happen when our guidelines are in place. 

I also agree with Alex that this dependency causes issues for 
testability.  Content developers should not be expected to be experts in

AT, nor should they be required to test with AT (a skill that is often 
completely outside the scope of content developers' interests and 
abilities, if not native users of AT). 

Lastly, what happens when content developers do what is deemed as 
"sufficient," but then AT competely changes it architecture of support 
-- we saw this with JAWS and Java Applets, where content developers 
needed to go back and completely change the way they had developed their

applications.  Again, I think we should be determining what is 
sufficient based on "reasonable" implementations of current technology, 
regardless of AT support.  It's not fair to chain content developers to 
either UA or AT.  As we said in Dublin.

This also brings up the question about AT Accessibility Guidelines -- if

we are to measure something against AT, we would want something 
comparable to UAAG, where we can say, "content developers do this, based

on UA doing this, if UA is coded to meet UAAG."  If UA is not coded to 
meet UAAG, the content developer should not have to contort themselves 
to accomodate -- instead, we should be working to get all UAs to comply 
with UAAG. I would love to see the same be true for AT -- we should have

AT Guidelines that then allow us to talk, in real terms, about 
interoperability.

As it stands, "sufficient" being deemed by what AT currently does today,

is not, in my opinion, at all reasonable, and binds the content 
developer to an ever-changing set of technologies, which should not be 
their responsibility.  We are going backwards in trying to put all the 
responsibility on the folks trying to meet WCAG, which I think is 
outside the scope of our work.

Thanks,
-Kerstin

Received on Friday, 6 January 2006 22:22:11 UTC