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:
- Requirements for what information must be communicated
through an API. These include:
- Read and limited write access to content (distinguishing HTML/XML
from other types of content).
- Read and limited write access to user agent user interface
components (programmatic control).
- User agent session variables: focus and selection.
- Notification of changes to content and user interface components
(event notification).
- Style information.
- Requirements for which APIs or types of APIs must be
used to communicate this information. These include:
- For XML/HTML content: use the W3C Dom Level 2 Core
- 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).
- For (CSS) style information, use the DOM Level 2 Style
Specification.
- Use of convential keyboard APIs for keyboard input.
- Requirements for additional characteristics of these
APIs. These include:
- Timely exchange of information
- 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:
- 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.
- 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.
- 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.
- 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:
- 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.
- The user agent's rendering is definitive; there is a high probability
of mismatch between the native rendering and an AT's own calculation.
- 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:
- It may not be the best API for meeting AT needs.
- 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.
- Some user agents may not implement the DOM 2 Core for XML and HTML, but
provide access to content nonetheless through another API.
- 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:
- 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.
- 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:
- Clear identification of "what must be available
through an API." Refer to the XML Infoset Recommendation to
define terms.
- 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.
- 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.
- 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.
- 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.
- Add a requirement for access to rendering
structure.
Additional steps outside the document:
- Improve collaboration between AT developers and API
designers within and outside of W3C, so that there are better standards
for access to rendering information.
- 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.