- From: Kerstin Goldsmith <kerstin.goldsmith@oracle.com>
- Date: Fri, 06 Jan 2006 10:23:44 -0800
- To: wcag <w3c-wai-gl@w3.org>
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 18:23:56 UTC