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

Re: User Agent Accessibility Guidelines

From: Jon Gunderson <jongund@staff.uiuc.edu>
Date: Fri, 01 Oct 1999 10:46:05 -0700
Message-Id: <4.1.19991001102612.00b1e1f0@staff.uiuc.edu>
To: Kasper Peeters <K.Peeters@damtp.cam.ac.uk>
Cc: w3c-wai-ua@w3.org
Responses in JRG:
At 07:43 PM 9/30/99 -0400, Ian Jacobs wrote:
>Kasper Peeters wrote:
>> Hi there,
>Hi Kasper,
>I'm cc'ing the UAGL Working Group with your comments and mine.
>> > I had a quick look at
>>    http://www.w3.org/WAI/UA/WAI-USERAGENT-19990827/.
>> In general, the idea is of course very good, but I doubt that it will
>> make much of a difference for the next generation browsers. 
>We have taken longer than expected to publish these Guidelines,
>> Some things are completely obvious, while others show that the authors of
>> this document have not looked beyond standard (mostly Windows)
>> solutions. 
>I'm surprised that you say that since we have considered software
>other than IE and NN and other platforms as well (I'm a Linux user,
>for one, and our colleagues use Lynx, Amaya, Opera, Home Page
>Reader, PWWebSpeak, Jaws, and other tools.)
>> This document has the flavour of being another excuse for
>> the big two to claim that they are standards compliant without
>> actually doing any innovative programming. I don't think I will loose
>> sleep if we fail to get the `Conformance Level A' mark. Appreciation
>> of open source software isn't shown by putting a big `W3C approved'
>> mark on it.

JRG: It is true that Microsoft has already put a lot of reasources into
making their browser more accessible, but there are still some areas they
can improve.  Mozillia/Netscape on the other hand has many things they need
to do to become more accessible.  The major purpose of the guidelines is to
highlight accessibility issues and provide strategies for their solution.
If the guidelines seem slanted toward GUI environment is probably because
that is where most of our concerns and contributions have originated from.
We would welcome solutions or accessibility issues from non-GUI
environments for including in the techniques document or as potential

>Our goal is not at all to give the big browser companies a means for
>displaying a token stamp of approval. The goal is to ensure
>that functional requirements of people with disabilities are 
>are being met by tools and to tell developers what those needs are.
>> A few random remarks (mostly negative, sorry):
>Better now than later.
>> - Some of the issues are so completely obvious that it seems silly to
>> even mention them. Using the `standard' API to communicate with input
>> devices, for instance. Although you might have a point here
>> considering the fact that eg. Mozilla is implementing its own GUI
>> toolkit from scratch.
>While you find this obvious (I'm glad), this is not always done in
>There is software that bypasses standard APIs (to improve performance
>I believe) and that throws off assistive technology that relies on
>standard system calls. 

JRG: Many people do not use standard methods in some parts of their
programs for various reasons.  We especially want to emphasize this since
many assistive technologies and OS accessibility features are only possible
or much easier for a developer to implement if people use OS conventions
and accessibility APIs.

>> - Installation and configuration is very much tied, at least on Unix,
>> to the particular flavour you are using (and for Linux, depends
>> crucially on which distribution you are running). These issues really
>> are outside of reach for browser developers.
>UA developers are not asked to make accessible what is not in their
>purview. We wouldn't ask you to make RPMs accessible. However,
>can choose formats for their documentation. We ask them to provide
>at least one accessible format. 

JRG: I don't think UNIX configuration tools are necessarily a problem,
since the ones I am familiar with use the a text based console device for
installation.  Most of our concerns are for GUI installation tools that are
not enheritly accessible and not compatible with assistive technologies.

>What specifically do you think we're asking developers to control that
>we shouldn't?
>> - Keyboard control is nice, but only up to a certain point. Using fake
>> (simulated) keyboard events to drive a program is a stupid way of
>> controlling things; adding scripting capabilities or a CORBA (or other
>> distributed OO) interface is the proper way to solve these problems.

JRG: Providing functionality is the key here.  We want all functionalities
of the user agent be accessible to through the keyboard.  So we want all
users to be able to do functions in device indepdent manner.  If there is a
pointer way to do an operation their should be a keyboard way of doing the
same operation.  The pointer and keyboard will be different, but the same
task can be accomplished.

Thank you for taking the time to review the UA guidelines document.  It is
important for the group to hear from developers like yourself, since we are
designing the document to be used by developers. 


Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Chair, W3C WAI User Agent Working Group
Division of Rehabilitation - Education Services
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
Received on Friday, 1 October 1999 11:41:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:38:23 UTC