Thoughts on where we are in User Agent Guidelines

Two important pieces of this summary/analysis are:

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.


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?


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:

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

Document status information



Table cells


Need to ensure that forms aren't submitted accidentally.

Form controls


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:

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:

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 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

Ensure compatibility with other software

Guideline covered here: 7.2


Ian B. Jacobs