Thoughts on where we are in User Agent Guidelines

Two important pieces of this summary/analysis are:

• Navigation is a means to an end (access to content and metadata). I would propose few navigation checkpoints (grouped together) and that most navigation stuff be moved to techniques.
• Guidelines specifically for links, forms, and tables should be dropped. These aren't principles.

Many thanks to Charles for discussing the guidelines with me.

Principles of accessible design

Although my summary almost fits within the four principles of design as listed in the 31 March UAGL Working Draft:

1. Ensure that content is accessible.
2. Ensure that the user interface is accessible.
3. Help the user remain oriented
4. Use standard interfaces and operating system conventions.

I would modify them as follows for this summary (and perhaps for the document if they are met with approval):

1. Ensure access to document content. Rationale: This is what Web browsing is about.
2. Ensure access to document metadata. Rationale: Metadata helps to orient users.
3. Provide navigation mechanisms. Rationale: Navigation provides access to content and metadata.
4. Ensure access to user agent functionality. Rationale: The user agent must be accessible in order to access content.
5. Ensure compatibility with other software. Rationale: Use of standard interfaces and OS conventions will promote consistency and interoperability among tools.

Guidelines

Note. One problem I have with the 31 March version of the guidelines is that some of the guidelines are not actually principles, notably the ones that read "Ensure that links/tables/forms are accessible. Therefore, the following sections reorganize and restate the guidelines of the 31 March draft according to the 5 principles listed above. The numbers of the 31 March guidelines are indicated where they are covered.

Ensure access to document content

Note. that there is no checkpoint in the guidelines that reads "Provide access to document content". Should there be, or is that so basic a principle that it's not worth saying explicitly?

Guidelines:

• Ensure that the user has final control of content rendering. This includes: turning on/off features (4.4) as well as being able to control styles (5.1). Pieces of guidelines 5.3, 5.4, and 5.5 are included here.
• Ensure that the user has access to alternative content (5.2).
• Support W3C Recommendations when appropriate (7.1) and support their accessibility features. For example, support HTML, CSS, XML, SMIL, MathML, and RDF.). This means authors can use these standards with confidence, they have accessibility features built-in, and they allow user control of style, for example.

Discussion of user interaction with the document is reserved for the section on access to user agent functionality.

Ensure access to document metadata

Pieces of guidelines 5.3, 5.4, 5.5, 6.1, 6.2, and 6.3 are included here.

Metadata describes element relationships, indicates status, or provides summary information. Some information is specified by the author or provided by the server. Other information is calculated by the user agent.

The following sections suggest some metadata to be provided by the UA for particular element types. Here are some questions:

• What should be a checkpoint? What should be a technique?
• What other information is required?
• What else should the UA synthesize? For example, should the user agent synthesize information such as navigation tools (from LINK elements) from metadata?

Note. I believe that Jon Gunderson's proposed subgrouping was approved by the Working Group and that this proposal requires assistive technologies only to provide this type of metadata.

Document content information

• Number of links/visited links.
• Number of tables.
• Number of forms.
• Number of frames.
• Primary language of content.

Document status information

• What percentage of the document has loaded?
• Loading has stalled
• Navigation is possible, even though the document is still loading.
• How much of the document has been viewed? (What is the position of the viewport?)

Links

• Number/id of this link.
• Internal or external.
• Visited or not.
• Whether involves a fee.

Tables

• Number/id of this table.
• Dimensions of table.
• Description (Caption, Summary, Headers)

Table cells

• Which table is this cell in?
• Position of this cell?
• Headers for this cell?

Forms

• Number/id of this form.
• Number of controls in the form.

Need to ensure that forms aren't submitted accidentally.

Form controls

• Which form is the control in?
• Associated label?

Frames

• Name of this frame

Provide navigation mechanisms

Pieces of guidelines 5.3, 5.4, 5.5, 6.2, and 6.3 are included here.

I see navigation as a way to give access to content (e.g., what's the text of this link?) and metadata (e.g., what are the dimensions of this table?). One navigates to elements in order to query them for content or metadata information.

While I'm tempted to suggest that all navigation is just a technique for providing access to content or metadata, I realize that the guidelines will probably need to require a small set of basic navigation functions to ensure accessibility and compatibility with current assistive technologies. What is the minimum set?

Basic navigation

A user agent provides access to content through a viewport. "Basic" access means that the user can move the viewport over the rendered content.

Other navigation mechanisms, in my opinion, are improvements on this basic mechanism. The first improvement one can think of is to allow the user to move the viewport forward at will. The next improvement is to allow backwards movement. Allowing the user to select how far to move the viewport or the dimensions of the viewport are additional improvements.

Sequential navigation

The next leap in serial navigation is sequential access to some subset of the document's elements (e.g., tabbing navigation of links). Improvements on this mechanism include the ability to move backwards through the sequence as well as forwards. Being able to configure which elements should be navigated (e.g., links + headers) allows even more control. Note that configuration of sequential navigation addresses a number of issues the WG has dealt with, including:

• What are active elements?
• How to navigate to elements with event handlers?
• How to do navigation to block elements?

Direct access

Direct access improves on sequential access by eliminating the need to traverse long sequences. There are several ways to provide direct access to elements, including:

• based on content (e.g., first letter of link text).
• based on position (e.g., nth link in document).
• based on identifier (e.g., link with id="foo").
• based on cursor/pointing device.

Structured/semantic navigation

Access based on the document tree can allow rapid access to a particular subtree, but a complicated document tree may mean this navigation mechanisms is not always optimal.

Navigation based on semantic relationships is also valuable (e.g., treat H3 as child of H2). Since element semantics are known in HTML, the UA may offer some pre-defined semantic navigation mechanisms. This won't be possible for XML unless (a) semantics are defined in a specification or (b) schemas are used to specify semantic relationships.

Searching

Searching can also provide rapid access to content. Note that text searching may span element borders. Some searching mechanisms include searching on element content or attribute values.

One can imagine more and more sophisticated mechanisms, including searching with regular expressions, searching with tree fragments, etc.

Focus and selection

The focus and selection identify elements or parts of elements (focus is used specifically to identify active elements, prior to activating them). They are (common) techniques for ensuring access to document content or functionality. The focus, for example, is an intermediate step between navigation and activation.

Ensure access to user agent functionality

• Provide accessible documentation. Document accessibility features. (Part of 4.1).
• Ensure device-independent operation of functionalities of UA and the document, including installation, configuration, link/form control activation, and navigation. (4.2, Part of 4.1) Note that keyboard access (4.3) is a kind of special case outside of device-independence that is here to ensure accessibility for many users.
• Allow UA configuration, including of keyboard access, user profiles, style profiles, navigation mechanisms, etc. (Part of 4.1, 4.3, 7.2).

Ensure compatibility with other software

Guideline covered here: 7.2

Checkpoints:

• Make information available to assistive technologies. This includes document content, status information (e.g., number of visited links, and user interface information (e.g., selection and focus). There are some security/privacy issues here (e.g., visited links). Also ATs should probably be able to write as well as read some information (e.g., to move the focus, to generate content, etc.). Performance issues are important here, and techniques will show different ways to have processes communicate.
• Use operating system conventions to exchange information.
• When applicable use the W3C DOM.