RE: programatically determineds

I agree wholeheartedly with this. 

We should watch carefully to be sure that none of our techniques or success
criteria pose any barrier to those who want to go further and experiment
(today) or implement (tomorrow) things that go beyond what is current
practice or known and tested ways of access today. 

This is subtle, so we need to watch for it - not just assume that what is
good today can't possibly block better tomorrow. 

 
Gregg

 -- ------------------------------ 
Gregg C Vanderheiden Ph.D. 
Professor - Ind. Engr. & BioMed Engr.
Director - Trace R & D Center 
University of Wisconsin-Madison 


-----Original Message-----
From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf
Of Lisa Seeman
Sent: Thursday, January 12, 2006 2:04 AM
To: Kerstin Goldsmith; wcag
Subject: Re: programatically determineds


Hi

Let me try and widen this perspective. We must make sure that we do not
discourage the evolution of  better user experiences and techniques. That is
why we need the programmatically determined phrase.
Many screen readers for People with learning disabilities are downloadable
from enabled sites , for free. For elearning material this a great way
forward where typical implementations and well known readers geared to the
blind community fall short of the task of addressing barriers of
understanding.

 For example. For some DAISY (Accessible for the blind and learning
disabled) books we create are "knowledge rich" extended DAISY that are great
for struggling students. We also work closely  with a (smallish) user agent
that  works with our extra knowledge, knows what to do, has alternate
presentations and has the coolest user experience for struggling students. 
(My opinion anyway). People can then get the content with the reader
together.


The way forward is, in my opinion beyond what well known AT are doing today,
and beyond the standard techniques. Addressing mainstream adoption of
current accessibility practices is important. But we should not stand in the
way of what we know now to be possible in terms of overcoming barriers and
creating a good user experience for all.


All the best
Lisa Seeman

----- Original Message -----
From: "Kerstin Goldsmith" <kerstin.goldsmith@oracle.com>
To: "wcag" <w3c-wai-gl@w3.org>
Sent: Friday, January 06, 2006 8:23 PM
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 Thursday, 12 January 2006 15:25:52 UTC