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

Re: PROPOSAL: Assistive Technology Checkpoints in the Guidelines

From: Ian Jacobs <ij@w3.org>
Date: Tue, 09 Feb 1999 09:54:00 -0500
Message-ID: <36C04C08.1B83A032@w3.org>
To: Denis Anson <danson@miseri.edu>
CC: Jon Gunderson <jongund@staff.uiuc.edu>, w3c-wai-ua@w3.org
Denis Anson wrote:
> 
> Ian,
> 
> I don't see how we can separate access to web content from access to the web
> browser.  Without access to the controls of the browser, the user would
> necessarily have limited access to the functionality of the browser, and
> hence to the web via the browser.

I think we are talking about two kinds of access:
 1) Access through the user interface
 2) Programmatic access.

For case (1), the guideline that requires device-independent
access to all functionalities offered by the user interface
should suffice. 

For case (2), one can distinguish access to the document structure
from control of the user interface proper. I am forwarding the
idea that these guidelines should not address programmatic
control of user interface controls. It would certainly be
interesting to have programmatic control of *everything*, but 
attempting to achieve that would grind the process of producing
these guidelines to a halt. Broad checkpoints such as "Ensure that the
user interface follows principles of accessible design" do
not belong in this document for similar reasons: we should limit
ourselves as much as possible to addressing the accessibility of
the content.

As I've mentioned in an earlier email, we do address the user
interface in several ways:

  - Device-independence (access to functionality, as well
      as installation, configuration, and access to help)
  - Keyboard access
  - Accessible electronic documentation formats
  - Configuration profiles

Thus, user interface issues do appear in the document. However,
I think trying to limit where they appear will enable us to
move forward more rapidly. 

> The mandate of the group is to create guidelines for user agents to provide
> access to the web for persons with disabilities.  It would seem that the
> browser controls fall well within that mandate. 

I still feel as though general user interface accessibility
issues lie outside the scope of this document. 
Here's a quote from Chuck Opperman from the MIT face-to-face
meeting minutes (11 Dec 1999) [1]:

   <BLOCKQUOTE>
   This is a very difficult problem: making a user
   interface and one that's accessible. Not
   the goal of this group (making content accessible). 
   There are plenty of good references about how to make 
   an interface accessible.
   Don't ignore the issue, just don't want to spent a lot of 
   time on this issue. Use platform guidelines. 
   Let's worry about HTML-specific issues.
   </BLOCKQUOTE>

[1] http://www.w3.org/WAI/UA/1998/12/wai-ua-f2f-19981211.html#minutes

Apparently this is an issue that needs resolution at the
next teleconference.


>  To suggest an extreme case,
> suppose a browser were to implement all of the suggest methods of
> controlling web content, but were to implement them in a way that made the
> use of AT to access those controls impossible? 
> For example, suppose the
> keyboard controls provided were implemented by reading the keyboard
> directly, so that there were no hooks for alternative keyboards to control
> the program.  In that case, the browser could say that it had implemented
> the guidelines fully, but it would still be inaccessible to people with
> disabilities.  We need to guarantee that the browser, as well as its content
> is accessible.

It's always possible to do something wrong. We should try
our best to promote what's right and indicate what's
the wrong way to do something, but we cannot prevent someone
somewhere from doing the wrong thing.

 - Ian

-- 
Ian Jacobs (jacobs@w3.org) 
Tel/Fax: (212) 684-1814 
http://www.w3.org/People/Jacobs
Received on Tuesday, 9 February 1999 09:54:55 GMT

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