Proposed changes to UAAG 1.0, Guideline 6

Status of this document

This proposal is written per an action of the 16 May 2002 UAWG teleconference to address issue 529 and issue 532. The purpose of this proposal is to rewrite the Guideline 6 checkpoints in light of a proposal from Ian and Jon. This proposal is for discussion by the UAWG at the 23 May 2002 teleconference.

Comments on the proposal

6.1 is now about information items only, for HTML and XML content. It merges the read and write requirements of the old 6.1/6.2.
6.2 is about APIs used to provide access to the information items of 6.1. The checkpoint makes it clearer that structure programmatic access is required.
6.3 is for non-XML and non-HTML content. Unlike 6.1, the XML Infoset no longer applies, so it is difficult to say generally what information types are required. The API cascade of 6.2 is reused here and in the checkpoints that follow.
6.4 New checkpoint for "structured programmatic read access to visually rendered information. The Note after 6.4 tries to convey goals of (1) structured access to rendered information and (2) connection between rendered information and content.
6.5-6.8 are unchanged except shortened and refer to API cascade of 6.2
6.9 (CSS module) is only for UAs in java/ecmascript environment. Otherwise, checkpoint 6.4 is expected to cover access to style information. 6.9 is almost a special case of 6.4 that ensures the link between content and some style information.
6.10 has been clarified to refer to APIs of guideline 6. This is a proposal for addressing issue 532.

Revised checkpoints

6.1 Access to XML and HTML content.(P1)

Provide programmatic read access to XML content by making available all of the information items defined by the W3C XML Infoset [Infoset].
Provide programmatic read access to HTML content by making available the following information items defined by the W3C XML Infoset [Infoset]:
1. The Document Information item: children, document element, base URI, charset
2. Element Information items: element-type name, children, attributes, parent
3. Attribute Information items: attribute-type name, normalized value, specified, attribute type, references, owner element
4. Character Information items: character code, parent element
5. Comment Information items: content, parent
If the user can modify HTML and XML content (e.g., form controls) through the user interface, provide the same functionality programmatically.

6.2 APIs for access to XML and HTML content.(P1)

If the user agent operating environment is java or ecmascript, provide read and write access to the content required by checkpoint 6.1 by conforming to the following modules of the W3C Document Object Model DOM Level 2 Core Specification [DOM2CORE] and exporting normative bindings for the interfaces they define:
- the Core module for HTML;
- the Core and XML modules for XML.
Otherwise, provide structured programmatic read and write access to the content required by checkpoint 6.1 by implementing at least one API according to this "API cascade":
1. The API is defined by a W3C Recommendation, or the API is publicly documented and designed to enable interoperability with assistive technologies.
2. If no such API is available, or if available APIs do not enable the user agent to satisfy the requirements:
  - implement at least one publicly documented API to satisfy the requirements, and
  - follow operating environment conventions for the use of input and output APIs.

Normative definitions:

Structured programmatic access means access through an API to recognized information items of the content. For XML and HTML content, an API that only offers a stream of characters does not qualify as providing structured programmatic access.
An API is considered available if the specification of the API is published (e.g., as a W3C Recommendation) in time for integration into a user agent's development cycle.

Note to Working Group: For this checkpoint, Rich Schwerdtfeger proposes instead that, outside of java and ecmascript, the DOM API must be used, and the requirement is to document the binding that it used. The current proposal implies that the DOM is sufficient but not necessary to satisfy the checkpoint.

6.3 Programmatic access to non-HTML/XML content.(P1)

For markup languages other than HTML and XML, provide structured programmatic read access to content and write access for those parts of content that the user can modify through the user interface.
Satisfy these requirements by implementing at least one API according to the API cascade of provision 2 of checkpoint 6.2.

Note: This checkpoint addresses content not covered by checkpoints checkpoint 6.1 and checkpoint 6.2.

6.4 Programmatic access to rendering structure.(P1)

For graphical user agents, provide structured programmatic read access to visually rendered information.
Satisfy these requirements by implementing at least one API according to the API cascade of provision 2 of checkpoint 6.2.

Note: The API that provides access to visually rendered information should provide access to both structured information and pixel-level information. When possible, it is useful to be able to refer to content programmatically by starting with its rendering, and vice-versa.

6.5 Programmatic access to user agent user interface controls.(P1)

Provide programmatic read access to user agent user interface controls.
Provide programmatic write access for those controls that the user can modify through the user interface. For security reasons, user agents are not required to allow instructions in content to modify user agent user interface controls.
Satisfy these requirements by implementing as least one API according to the API cascade of provision 2 of checkpoint 6.2.

For user agent features.

Note: APIs used to satisfy the requirements of this checkpoint may be platform-independent APIs such as the W3C DOM, conventional APIs for a particular operating environment, conventional APIs for programming languages, plug-ins, virtual machine environments, etc. User agent developers are encouraged to implement APIs that allow assistive technologies to interoperate with multiple types of software in a given operating environment (user agents, word processors, spreadsheet programs, etc.), as this reuse will benefit users and assistive technology developers. User agents should always follow operating environment conventions for the use of input and output APIs.

6.6 Programmatic alert of changes.(P1)

Provide programmatic alert of changes to content, user interface controls, selection, content focus, and user interface focus.
Satisfy these requirements by implementing as least one API according to the API cascade of provision 2 of checkpoint 6.2.

For both content and user agent.

Note: For instance, when user interaction in one frame causes automatic changes to content in another, provide a programmatic alert. This checkpoint does not require the user agent to alert the user of rendering changes caused by content (e.g., an animation effect or an effect caused by a style sheet), just changes to the content itself.

6.7 Conventional keyboard APIs.(P1)

Follow operating environment conventions when implementing APIs for the keyboard.
If such APIs for the keyboard do not exist, implement publicly documented APIs for the keyboard.

Note: An operating environment may define more than one conventional API for the keyboard. For instance, for Japanese and Chinese, input may be processed in two stages, with an API for each.

6.8 API character encodings.(P1)

For an API implemented to satisfy requirements of this document, support the character encodings required for that API.

For both content and user agent.

Note: Support for character encodings is important so that text is not "broken" when communicated to assistive technologies. For example, the DOM Level 2 Core Specification [DOM2CORE], section 1.1.5 requires that the DOMString type be encoded using UTF-16. This checkpoint is an important special case of the other API requirements of this document.

6.9 DOM CSS access.(P2)

For user agents that implement Cascading Style Sheets (CSS), ff the user agent operating environment is java or ecmascript, provide programmatic access to those style sheets in content by conforming to the CSS module of the W3C Document Object Model (DOM) Level 2 Style Specification [DOM2STYLE] and exporting the interfaces it defines.

Normative definition:

For the purposes of satisfying this checkpoint, Cascading Style Sheets (CSS) are defined by either CSS Level 1 [CSS1] or CSS Level 2 [CSS2].

Note: Please refer to the "Document Object Model (DOM) Level 2 Style Specification" [DOM2STYLE] for information about CSS versions covered. For other operating environments, checkpoint 6.4 is expected to provide access to rendering information.

6.10 Timely access.(P2)

For an API implemented to satisfy the requirements of this document, ensure that programmatic exchanges proceed in a timely manner.

For both content and user agent.

Note: For example, the programmatic exchange of information required by other checkpoints in this document should be efficient enough to prevent information loss, a risk when changes to content or user interface occur more quickly than the communication of those changes. Timely exchange is also important for the proper synchronization of alternative renderings. The techniques for this checkpoint explain how developers can reduce communication delays. This will help ensure that assistive technologies have timely access to the document object model and other information that is important for providing access.

Original checkpoints (12 Sep 2001 versions)

6.1 DOM read access. (P1)

Provide programmatic read access to HTML and XML content by conforming to the following modules of the W3C Document Object Model DOM Level 2 Core Specification [DOM2CORE] and exporting the interfaces they define:
- the Core module for HTML;
- the Core and XML modules for XML.

Note: Please refer to the "Document Object Model (DOM) Level 2 Core Specification" [DOM2CORE] for information about HTML and XML versions covered.

6.2 DOM write access. (P1)

If the user can modify HTML and XML content through the user interface, provide the same functionality programmatically by conforming to the following modules of the W3C Document Object Model DOM Level 2 Core Specification [DOM2CORE] and exporting the interfaces they define:
- the Core module for HTML;
- the Core and XML modules for XML.

Note: For example, if the user interface allows users to complete HTML forms, this must also be possible through the required DOM APIs. Please refer to the "Document Object Model (DOM) Level 2 Core Specification" [DOM2CORE] for information about HTML and XML versions covered.

6.3 Programmatic access to non-HTML/XML content. (P1)

For markup languages other than HTML and XML, provide programmatic read access to content.
Provide programmatic write access for those parts of content that the user can modify through the user interface. To satisfy these requirements, implement at least one API that is either
- defined by a W3C Recommendation, or
- a publicly documented API designed to enable interoperability with assistive technologies.
If no such API is available, or if available APIs do not enable the user agent to satisfy the requirements, implement at least one publicly documented API to satisfy the requirements, and follow operating environment conventions for the use of input and output APIs.
An API is considered available if the specification of the API is published (e.g., as a W3C Recommendation) in time for integration into a user agent's development cycle.

Note: This checkpoint addresses content not covered by checkpoints checkpoint 6.1 and checkpoint 6.2.

6.4 Programmatic operation. (P1)

Provide programmatic read access to user agent user interface controls.
Provide programmatic write access for those controls that the user can modify through the user interface. For security reasons, user agents are not required to allow instructions in content to modify user agent user interface controls.
To satisfy these requirements, implement at least one API that is either
- defined by a W3C Recommendation, or
- a publicly documented API designed to enable interoperability with assistive technologies.
If no such API is available, or if available APIs do not enable the user agent to satisfy the requirements, implement at least one publicly documented API that allows programmatic operation of all of the functionalities that are available through the user agent user interface, and follow operating environment conventions for the use of input and output APIs.
An API is considered available if the specification of the API is published (e.g., as a W3C Recommendation) in time for integration into a user agent's development cycle.

For user agent features.

6.5 Programmatic alert of changes. (P1)

Provide programmatic alert of changes to content, user interface controls, selection, content focus, and user interface focus.
To satisfy these requirements, implement at least one API that is either
- defined by a W3C Recommendation, or
- a publicly documented API designed to enable interoperability with assistive technologies.
If no such API is available, or if available APIs do not enable the user agent to satisfy the requirements, implement at least one publicly documented API to satisfy the requirements, and follow operating environment conventions for the use of input and output APIs.
An API is considered available if the specification of the API is published (e.g., as a W3C Recommendation) in time for integration into a user agent's development cycle.

For both content and user agent.

6.6 Conventional keyboard APIs. (P1)

Follow operating environment conventions when implementing APIs for the keyboard.
If such APIs for the keyboard do not exist, implement publicly documented APIs for the keyboard.

Note: An operating environment may define more than one conventional API for the keyboard. For instance, for Japanese and Chinese, input may be processed in two stages, with an API for each.

6.7 API character encodings. (P1)

For an API implemented to satisfy requirements of this document, support the character encodings required for that API.

For both content and user agent. Techniques for checkpoint 6.7

6.8 DOM CSS access. (P2)

For user agents that implement Cascading Style Sheets (CSS), provide programmatic access to those style sheets in content by conforming to the CSS module of the W3C Document Object Model (DOM) Level 2 Style Specification [DOM2STYLE] and exporting the interfaces it defines.
For the purposes of satisfying this checkpoint, Cascading Style Sheets (CSS) are defined by either CSS Level 1 [CSS1] or CSS Level 2 [CSS2].

Note: Please refer to the "Document Object Model (DOM) Level 2 Style Specification" [DOM2STYLE] for information about CSS versions covered.

6.9 Timely access. (P2)

Ensure that programmatic exchanges proceed in a timely manner.

For both content and user agent.

Ian Jacobs. Last modified: $Date: 2002/05/20 16:10:02 $