W3C home > Mailing lists > Public > w3c-wai-ua@w3.org > October to December 2000

Re: Last call comments from WCAG working group

From: Jon Gunderson <jongund@ux1.cso.uiuc.edu>
Date: Wed, 06 Dec 2000 11:16:50 -0600
Message-Id: <4.3.1.2.20001206110614.028ef008@staff.uiuc.edu>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 06:50:22 GMT