- From: Jon Gunderson <jongund@ux1.cso.uiuc.edu>
- Date: Wed, 06 Dec 2000 11:16:50 -0600
- To: Wendy A Chisholm <wendy@w3.org>, Ian Jacobs <ij@w3.org>, Jason White <jasonw@ariel.ucs.unimelb.edu.au>, gv@trace.wisc.edu
- Cc: w3c-wai-ua@w3.org
Responses in JRG: >> > 12. Several checkpoints refer to using operating system conventions. What >> > about a user agent that is written in Java? >> > In that case it is up to the >> > virtual machine to use the system conventions. >> >>Is that entirely true? I thought that the virtual machine's >>job was to interpret byte code, but that you could write >>programs to do whatever you want. I am not a Java >>programmer... > >The virtual machine interprets byte codes into something the OS can >understand. The VM is operating system specific. JRG: If the developer is relying on the VM for some accessibility functionalities required by UAAG, the developer may only be able to claim conformance for certain operating systems that they can demonstrate actually meet the guidelines. Therefore they may not be able to claim conformance for every OS with a Java VM. >>Section 3.2 is about using OS features as part of >>conformance claims. I'm not sure I understand your >>comment. Also, do you have an alternative conformance scheme >>to suggest? Please note that the Working Group has worked >>extremely hard to come up with this conformance scheme and I >>don't think the WG will readily change it without a very >>concrete counter-proposal. > >It was my understanding of this section that if a standard accessibility >API does not exist for an operating system, that the developer must create >and use their own. This would cause an AT developer to learn a different >API for each browser on a platform that did not have an accessibility API. > ><blockquote> >Developers are encouraged to adopt operating system conventions and >features that benefit accessibility to meet the requirements of this >document. However, if these features are not accessible, developers must >provide an alternative accessible solution. ></blockquote> > >For example, say the NewWebOS (fictional) does not have any operating >system conventions and features that benefit accessibility. Browsers Y >and X run on NewWebOS and want to conform to UAAG 1.0. These browsers use >the system's paint methods. These methods draw text pixel by pixel. What >is the alternative accessible solution that the browsers provide? They >will have to write their own API for an AT to use to get text. If X and Y >do something different, AT developer Z will have to learn both of their >methods. > >This happens today and thus why JAWS works better with IE than with >Netscape - JAWS has more access to what IE knows and does. I thought one >of the goals of encouraging the use of system APIs is that the AT >developers will only need to learn the standard API and not all of the >home grown variations. > >In the case where an OS does not have standard APIs with accessibility >features we need to encourage developers to push the OS for a solution >rather than create their own. Perhaps until the OS provides a solution >they can provide a kludge,but in that case they should also work carefully >with AT developers. > >Thus, I propose (and this needs work): ><blockquote> >Developers are encouraged to adopt operating system or language >conventions and features that benefit accessibility to meet the >requirements of this document. However, if these features are not >accessible, developers must work with assistive technologies on that >platform (or language) to provide an alternative accessible solution and >should work with the operating system manufacturer or other third parties >to create accessibility conventions and features for that OS (or standard >API - in the case of Java). ></blockquote> > >I don't know how browser manufacturers will feel about this, but I do >think we should rely on the OS or language as much as possible to provide >standard features that ATs can hook into. That's what Active >Accessibility and the Java Accessibility APIs were all about. > >If you can find another way to clarify this or if you don't think it needs >clarification, I'm fine with that. But this was my interpretation >(or misinterpretation, as the case might be). JRG: Again the user agent developer would need to show how there device communicates information to assistive technologies. For proprietary operating system/user agent combination that do not have assistive technologies there proably need to be a different set of guidelines, more like the section 508 guidelines that state a person with a visual impairment must be able to XXX independently. The more this type of issue comes up the more I think we should be calling this version of UAAG the desktop version. Primarily for user agents running on operating systems designed for general purpose use. There is probably a need for another set of guidelines for user agents that are "stand-alone" or "Kiosk" based that Wendy describes. Jon Gunderson, Ph.D., ATP Coordinator of Assistive Communication and Information Technology Division of Rehabilitation - Education Services MC-574 College of Applied Life Studies University of Illinois at Urbana/Champaign 1207 S. Oak Street, Champaign, IL 61820 Voice: (217) 244-5870 Fax: (217) 333-0248 E-mail: jongund@uiuc.edu WWW: http://www.staff.uiuc.edu/~jongund WWW: http://www.w3.org/wai/ua
Received on Wednesday, 6 December 2000 12:15:44 UTC