Your response SVG group's response to UA Guide

Ian,

As usual you have done a stellar job here.

I have a few comments that we might like to add:

Response to A.3 Conformance Icons:

Our response should mention that due to the large number of XML-based
grammars being produced by the W3C it is unrealistic for a User Agent to
expect that the W3C User Agent group will write a verification tool for
every renderable XML grammar.

The SVG group proposed two main scenarios where conformance icons make
sense. I agree with number 1 where the icon only means that claims have
been made. A real certification tool is unlikely ... particularly if the
infrastructure does not support such a tool.

B.2 Checkpoint 4.2 Control of font families burdensome in SVG

Apache Batik has a CSS2 DOM API implementation that I believe controls font
families.

B.3 Checkpoint 6.5: Alert changes in UI is burdensome

How does the SVG group think a blind person would know if the UI changes
unless they are told. They need to be sensitized to this problem.
Recommendation: The Education and Outreach WAI group should work with SVG
working group members since there is a lack of understanding.

B.4 Checkpoint 10.3 Higlighting requirement should refer to text links:

Any element navigable by the user requires visible feedback. Example: if 10
links exist in an image map and they are navigable how does a user know
which one they are on. A blind user as well as a low vision or cognitively
impaired user would need visual or auditory assistance here.

C.3 The UAAG 1.0 reuirements do not make sense for all formats or types of
user agents.

This would be the largest document known to mankind. At the rate that the
W3C turns out new grammars and the industry turns out new user agents
designed to support different client devices we would never keep up. I
think the SVG group is getting carried away.

C.4 W3C specificationsshould not require implementation of operating
environment features for conformance.

The SVG viewers I have seen were written in Java and can easily support the
Java Accessibility API (these are Java specific but platform neutral).
Support of the DOM API would also be required but this is also platform
neutral.

C.5 UAAG 1.0 too hard to implement:

This is because the SVG has done little to create an accessible
infrastructure for their user agents. Standards for accessible software
have existed for some time. The SVG group has appeared to ignore them. It
is always hard to go back when you have ignored the problem for so long.

The addressing of classes of devices cannot be done at this time. Industry
trends change constantly. It is unrealistic for any group to think that we
can address them all. The basics are addressed here. Addressing mobile
devices in this version 1.0 of the guidelines is unrealistic. Besides, NO
assistive technologies work with them anyways.




Rich Schwerdtfeger
Senior Technical Staff Member
IBM Accessibility Center
Research Division
EMail/web: schwer@us.ibm.com

"Two roads diverged in a wood, and I -
I took the one less traveled by, and that has made all the difference.",
Frost

Received on Thursday, 12 July 2001 14:04:38 UTC