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]:
- The Document Information item: children, document element, base
URI, charset
- Element Information items: element-type name, children, attributes,
parent
- Attribute Information items: attribute-type name, normalized value,
specified, attribute type, references, owner element
- Character Information items: character code, parent element
- 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.
- 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":
- The API is defined by a W3C Recommendation, or
the API is publicly documented and
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:
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.
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.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.
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.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
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.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.
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.
Ian Jacobs. Last modified: $Date: 2002/05/20 16:10:02 $