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 08:04:14 UTC