[Summary] Main points of 31 May teleconference with AT developers

Hello,

I'd like to summarize what I thought the main points were from the 31
May 2001 UAWG teleconference [1]. Please note that these 
comments are my own and do not represent agreement within the UAWG.
I welcome additional observations about the meeting.

Note: The title of the email of the minutes [1] incorrectly reads "13
May" instead of "31 May". Sorry about that!
[1] http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0230

-----------------------
CONSENSUS ABOUT THE DOM
-----------------------

The AT developers on the call were enthusiastic about the DOM
requirements for content. Some minuted comments from different AT
developers:

 - "If browsers implemented the DOM then we would switch. If they
 build it into the browsers (and there's a convincing business
 argument that we wish to support those browsers), then we will
 switch."

 - "As long as the DOM is not implemented cross-platform, we have
 problems with it. We would be interested in using the
 DOM. Checkpoints 6.1 and 6.2 are important checkpoints."

 - "Right now, the majority of our access to content is through
 MSAA. If the browsers take off on DOM support, we will strongly
 look into support for it."

 - "So far, we have been looking at the IE DOM. If the W3C DOM were
 available, then we would use it."

------------------------------------------
SOME DISAGREEMENT ABOUT USE OF APIS OTHER THAN THOSE OF
OPERATING ENVIRONMENT
------------------------------------------

As of the 4 June draft [2], the UAWG has preferred the following
"cascade" of APIs for providing access to UI controls (e.g.,
checkpoint 6.4):

 a) Use a W3C Recommendation where available, or
    an API designed for interoperability with assistive 
    technologies.
 b) If such APIs are broken or don't exist, use publicly
    documented APIs and follow standard input/output.

[2] http://www.w3.org/WAI/UA/WD-UAAG10-20010604/

At the 31 May teleconference, there was some disagreement about
whether any API designed for interoperability with assistive
technologies was sufficient, or whether there needed to be a
preference for standard accessibility APIs for an operating
environment *first*. [I note that UAAG 1.0 has never had an API
requirement for an operating environment API before any other.]

At least two people on the call felt that (b) was insufficient for at
least two reasons:

 1) Each API is a burden for AT developers to implement. So
    allowing conformance for potentially several APIs 
    made some AT developers nervous.

 2) Requiring implementation of the standard accessibility
    API of a particular operating environment means that
    it is more likely that ATs will work with user agents
    and other software running in the same operating 
    environment.

There are a few reasons why UAAG 1.0 doesn't require
implementation of a particular operating environment's
standard API:

 1) It would be difficult for a W3C Recommendation
    to say "You must implement this vendor-specific
    API in order to conform." The current model allows
    for conformance by using vendor-specific APIs
    or any other API designed for interoperability
    with ATs.

 2) Requiring platform-specific APIs for conformance
    makes conformance for cross-platform user agents
    that much more difficult.

The risk cited by some of the developers on the call
was that an API might be designed for interoperability
with ATs, but not be very good, or tested, etc. I don't
think that this is a serious issue because:

 1) We've never had any requirements for "good" APIs.
    Even currently deployed APIs may suit the needs
    of some developers more than others.

 2) Each API checkpoint has two parts to it: (a) the 
    information that must be made available, and (b) the type
    of API for doing so. I think that the APIs that some 
    developers feared might allow conformance while not 
    being truly adequate would fail part (a) before part (b).

Comments:

 1) After the teleconference, Rich (of IBM) wrote [3]
    
    "Regarding the checkpoints in guideline 6.0 but more specifically
    checkpoint 6.4. If the checkpoint would emphasize the importance
    of environment-specific APIs I would be satisfied with the
    checkpoint."

    [3] http://lists.w3.org/Archives/Public/w3c-wai-ua/2001AprJun/0231

 2) Thus, perhaps we can move forward by indicating the value
    of operating environment APIs, but not requiring them for
    conformance to the exclusion of other options. Some advantages
    include:
       a) Cross-software interoperability on the same
          platform. Note: AT developers indicated that in any case,
          there needs to be additional work done for each piece of
          software with which the AT communicates.

       b) Advantageous to both UA and AT developers to reuse 
          existing APIs.

 3) As to the concern raised about the number of APIs that have
    to be implemented: While the UAWG is aware of implementation
    burdens by both browser developers and AT developers, this
    has not been a fundamental criterion in how we have chosen
    our requirements.

-- 
Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
Tel:                     +1 831 457-2842
Cell:                    +1 917 450-8783

Received on Monday, 4 June 2001 15:48:53 UTC