W3C

Summary of status of UAAG 1.0 API requirements

This version:
http://www.w3.org/WAI/UA/2002/04/api-summary
Editors:
Ian Jacobs, W3C
Jon Gunderson, University of Illinois at Urbana-Champaign
Last modified:
$Date: 2002/05/21 16:39:45 $

Copyright © 2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

Status of this Document

This document has been produced by the editors as a status report on UAAG 1.0 API requirements and a proposal for moving forward after the UAAG 1.0 Second Candidate Recommendation period. This document does not represent the consensus of the User Agent Accessibility Guidelines Working Group, but has been produced for their review.

The reference version of UAAG 1.0 for this update is the 13 September 2001 version.

Introduction

The User Agent Accessibility Guidelines 1.0 includes requirements to promote interoperability between conforming user agents and assistive technologies, such as screen readers, screen magnifiers, alternative keyboards, and more; see more information on assistive technologies in "How People with Disabilities use the Web". There are three types of API requirements in Guideline 6 of UAAG 1.0:

  1. Requirements for what information must be communicated through an API. These include:
    1. Read and limited write access to content (distinguishing HTML/XML from other types of content).
    2. Read and limited write access to user agent user interface components (programmatic control).
    3. User agent session variables: focus and selection.
    4. Notification of changes to content and user interface components (event notification).
    5. Style information.
  2. Requirements for which APIs or types of APIs must be used to communicate this information. These include:
    1. For XML/HTML content: use the W3C Dom Level 2 Core
    2. For other types of content, use the "best API", where there is a cascade of APIs available that conveys a preference for publicly documented APIs designed for interoperability with assistive technologies (see checkpoint 6.4 for the full cascade).
    3. For (CSS) style information, use the DOM Level 2 Style Specification.
    4. Use of convential keyboard APIs for keyboard input.
  3. Requirements for additional characteristics of these APIs. These include:
    1. Timely exchange of information
    2. Respect for character encodings

Current limitations of UAAG 1.0

In each category of the requirement, there have been questions throughout the life of UAAG 1.0. Below we discuss two aspects of the question "Does the W3C DOM specification meet AT needs?"

Note: In recent UAWG discussions, we have also talked about some aspects of category three, such as thread-safe communication and ensuring that APIs are capable of preserving document order. These questions are not addressed in this summary.

What information must be available to ATs?

Depending on the nature of the application, some assistive technologies may benefit more from logical information (i.e., "content") while others may required rendering information. For instance, screen magnifiers rely heavily on what's really rendered in the (host) user agent. UAAG 1.0 has promoted access to logical information rather than rendering information for at least the following reasons:

  1. It is common for assistive technologies to have to "reverse engineer" structure based on rendering, so UAAG 1.0 provides ATs with structured content so that reverse engineering is no longer necessary.
  2. There is no standard API for access to rendering structure. W3C has published the DOM Level 2 Views Recommendation, "a platform- and language-neutral interface that allows programs and scripts to dynamically access and update the content of a representation of a document." However, this API is so abstract as to not provide developers with much certainty about the information they should expect to be able to exchange, nor the interface for doing so.
  3. The DOM Level 2 Specifications work well together, and so UAAG 1.0 anticipated that developer efforts would be reduced overall by using the family of DOM APIs for access to content, content events, and style information.
  4. The UAWG felt that some approaches used by AT developers followed a "broken model" and that the DOM would provide a cleaner approach to information exchange.

However, it has become apparent from ongoing discussions with AT developers (e.g., see table of AT requirements) that the lack of a requirement for access to rendering information is a problem for UAAG 1.0. There are a couple of compelling reasons to include a requirement for access to rendering structure even where no standard API is available:

  1. A (host) user agent knows what information is available on the screen. Assistive technologies should not be required to recalculate what's on the screen because the work has already been done.
  2. The user agent's rendering is definitive; there is a high probability of mismatch between the native rendering and an AT's own calculation.
  3. Much HTML content on the Web is invalid. Some user agents generate rendering structure based on content that is different from what appears in the document object after repair. Thus, there is a mismatch between what's on the screen and what's available through the DOM.

Most parties agree that assistive technologies would benefit from a standard, detailed API providing accurate information about "what's on the screen," but at the present time, for example, the DOM WG is not pursuing this work.

One developer has suggested that the (AT) audience for access to logical information (through the DOM) is much smaller than the audience for access to rendering information: ATs that want the real logical structure tend to be more stand-alone products such as emacsspeak. The UAWG needs to do some work to confirm this assertion. If this is the case, UAAG 1.0 requirements may need revision to provide for access to rendering information.

Which APIs?

The UAWG has heard from some developers of both user agents and assistive technologies that UAAG 1.0 should not include a DOM requirement as a Priority 1 requirement for a number of reasons:

  1. It may not be the best API for meeting AT needs.
  2. AT developers may not rush to implement a "new" technology as they have substantial resources invested in other approaches, even where those approaches are imperfect.
  3. Some user agents may not implement the DOM 2 Core for XML and HTML, but provide access to content nonetheless through another API.
  4. Some assistive technology developers would like their applications to work on more than Web-based applications (such as word processors, spread sheet programs, etc.) and so requiring Web-centric APIs may be less desirable than more general APIs.

The UAWG has nonetheless continued to assert its preference for the DOM because it is platform-independent, it is likely to be implemented in most user agents, and we expect it to therefore promote interoperability. Periodic meetings with assistive technology developers (e.g., refer to survey of AT developers from first CR) suggested (but did not confirm with conviction) that the DOM requirements were appropriate and would meet AT needs.

Our work during this second CR period suggests that as written, the DOM requirements are insufficient. We have learned from discussions, for example that:

  1. Some assistive technology developers are dissatisfied with the DOM because what they really want is access to the rendering structure. The DOM does not give them all that they need or in the case of invalid HTML the DOM often does not represent what the user agent is rendering.
    Counter argument: No API (whether operating system standard, W3C standard, or other) provides all information; whatever UAAG 1.0 requires, AT developers are likely to have to use additional APIs for all the information they need.
  2. Some assistive technology developers have not found the DOM useful because there are only two normative bindings: Java and Ecmascript. Consequently, in other programming environments, there is no guarantee of interoperability between two user agents' implementations of the DOM. Thus, while UAAG 1.0 hopes to promote interoperability, limitations of DOM Level 2 Core have dissuaded some implementers.
    Counter argument: Even where there are not normative bindings, recommending the DOM is a good idea because it gives developers an idea of what they're getting, even if the API has been implemented differently from one piece of software to the next.

Moving forward

Note: The proposal below has been superseded by this proposal to the WG.

If we continue on our present path it does not appear that our document will influence future practice in terms of user agent-AT communication. Here is one proposal for moving forward with changes to UAAG 1.0:

  1. Clear identification of "what must be available through an API." Refer to the XML Infoset Recommendation to define terms.
  2. Require DOM where normative bindings: Once the set of information has been defined, require the DOM for access to XML and HTML content where normative bindings exist: in Java and Ecmascript.
  3. Recommend DOM otherwise: Even where bindings may vary, recommending the DOM as the API to provide access to XML/HTML content will promote predictability if not interoperability.
  4. Use existing API cascade for non-normative bindings: require publicly documented API designed for interoperability with ATs, or if not available, use of standard input/output APIs.
  5. Ensure structured access through an API: Clarify that one characteristic of APIs used to provide access to all content is that they preserve structure and document order. This was discussed at the 25 April 2002 UAWG teleconf.
  6. Add a requirement for access to rendering structure.

Additional steps outside the document:

  1. Improve collaboration between AT developers and API designers within and outside of W3C, so that there are better standards for access to rendering information.
  2. Investigate the capabilities and interests of AT developers and API designers within and outside of W3C, for the development of an XML grammar to represent the data required by AT developers and the development of DOM bindings (e.g., for C++ enviroments) that the AT community could rely on.