1-888-576-8932 (USA) 1-727-821-8315 (Int'l)

In addition, the document, entitled "Techniques for User Agent Accessibility Guidelines 1.0" [UAAG10-TECHS] was consulted for implementation examples to clarify the intent of various checkpoints and definitions.

The review will roughly follow the document's Table of Contents with regard to heading descriptions and section numbering. Section headings will be bracketed "[]" and review comments will be found beneath these headings.

For example:

[Abstract]

… comments about the abstract …

The following criteria were used in reviewing the document (in order of precedence):

1. Clarity / Consistency / Completeness
2. Appropriateness of Priorities
3. Implementation Practicality

In the opinion of this reviewer, this last call document is noticeably improved over that which was presented for last call review a year ago (User Agent Accessibility Guidelines 1.0 - W3C Working Draft-November-1999). Specifically, the abstract and introduction of the current document provide clearer, more direct statements of the purpose of the User Agent Accessibility Guidelines (UAAG), it's benefits and impact on User Agent developers and their end-users.

The organization of the document is also improved in terms of logical flow of topics and simplified section titles. The sections themselves, including individual checkpoints are well-written and contain a surprisingly small number of typographical errors give the amount and complexity of information being presented. Hopefully, the same can be said for the number of typos inevitably present in this review.

[1.2 Scope of the document]

In the fourth paragraph describing the relationship of the requirements set forth in the document to the installation of software … It might be helpful to note that not all user agents require installation of software. For example, mobile phones, standard telephones and other "thin-clients" may require only configuration as formally defined later in the document.

[Guideline 1]

Small typo in the second sentence of the first paragraph:

"Th[e] user must be able to operate the user interface with a variety of input devices … "

and the second sentence of the third paragraph:

" Developers should not, for example, pre-rasterize text or since doing so may prevent assistive technologies from being able to render the text as speech or Braille."

Perhaps either

" … should not, for example, pre-rasterize text for since doing so …"

-or-

" should not, for example, pre-rasterize text, since doing so "

was intended ?

[Checkpoint 2.5]

The note for the checkpoint states that when the content author does not provide text equivalents for content "… the user agent is required by this document to generate repair text.". However, the definition for "repair content, repair text" indicates that "This document does not require user agents to include repair content in the document object." Presumably the difference between the definition of Repair Content vs. Repair Text might explain these seemingly contradictory statements, but isn't Repair Text a type of, i.e. a subset of, Repair Content? In any case, some additional clarification might prove helpful.

[Guideline 3]

Kudos. The statement "A user agent must allow this configurability even when it passes content (e.g., a sound file) to the operating system or to a helper application for rendering; the user agent is aware of the content type and thus can choose not to render it." is an excellent reminder that the accessible user-agent acts as the ultimate gatekeeper of the content interface and is responsible for ensuring accessibility no matter what content may be encountered.

Along these lines, it is noteworthy to mention that repetitive and redundant content can reduce accessibility to a great extent. Consider the web page with multiple (sometimes 3 or more) redundant navigation bars (image maps, etc.) that must be rendered and played (in the case of a speech-synthesizer) each time the viewpoint is opened. This is at least as significant an impact on accessibility as blinking text, which has merited a Priority 1 ranking.

[Checkpoint 3.5]

Just a reminder that allowing the user to "configure the user agent not to execute scripts or applets" in many cases will result in no content being rendered, unless the content author has provided equivalent accessible content, which unfortunately is currently an uncommon situation.

[Checkpoints 3.6 and 3.7]

These checkpoints both discuss author-specified redirects (supported by a HTML META element with http-equiv="refresh"). However the "Techniques for checkpoint 3.6" refer the reader to information on the HTTP 1.1 specification [RFC2616] where there is no discussion of author-specified redirects, using HTML "refresh". This, even though checkpoint 3.6 clearly states that a "…. client-side redirect (i.e., one initiated by the user agent, not the server." is being considered. The "Techniques for checkpoint 3.7" appears to include the information applicable to both checkpoints.

[Checkpoint 3.8]

The ability to allow the user to configure the user agent not to render images seems worthy of a Priority 1 ranking. This is a key functionality, alluded to in 1.2 and appropriately identified in Guideline 2 has having an impact on rendering speed, thereby reducing overall accessibility.

[Checkpoint 4.13]

Even though the reader is referred to checkpoint 4.11, it might be more instructive to mention that this checkpoint "is a special case" of checkpoint 4.11.

[Checkpoint 4.14]

It might be useful to refer the reader to section 3.3 "Checkpoint applicability" in the circumstance that the speech synthesizer does not support changing the voice characteristics identified (e.g. gender, pitch, etc.). Specifically, the last exclusionary rule of checkpoint applicability "The checkpoint requires control of content properties (e.g., video or animation rate) that the subject cannot control (e.g., the format does not allow it) or does not recognize (e.g., because the property is controlled by a script in a manner that the subject cannot recognize)" would apply in this case.

For instance, the checkpoint might be rewritten as:

"Allow the user to configure synthesized voice gender, pitch, pitch range, stress, richness, and control of spelling, punctuation, and number processing according to the full range of speech characteristics and corresponding values offered by the speech synthesizer, except as exempted by section 3.3 "Checkpoint applicability".

[Checkpoints 4.1.6 and 4.1.7]

The note for these Priority 1 checkpoints refers the user to checkpoint 4.1.4 for information on control of speech output as it relates to highlighting. Should it be inferred that highlighting of speech output is a P1 or P2 user interface characteristic? I would suggest that it is P2 since the absence of speech output highlighting does not meet the standard set for Priority 1 checkpoints. Namely, that the checkpoint must be satisfied by user agents, otherwise one or more groups of users with disabilities will find it impossible to access the Web.

[Checkpoint 4.20]

Some brief examples might help illustrate the difference between this checkpoint and Checkpoint 4.18, both checkpoints being concerned primarily with automatic or manual (via explicit user request) opening of a new viewport. Is checkpoint 4.18 a special case of 4.20 ?

[Checkpoint 6.1]

Unless I have misinterpreted it's meaning, this Priority 1 checkpoint requires all accessibility features of all implemented specifications to be implemented such that they comply with all requirements of the Web Content Accessibility Guidelines. This suggests Triple-A compliance on the web content (server) side that must be met with the highest level of accessibility by the user agent. Are we sure we want to make this extreme level of compliance mandatory? Returning to the definition of Priority 1, do we truly believe that unless all accessibility features and all requirements imposed by the WCAG are met, one or more groups of users with disabilities will find it impossible to access the Web? It seems that lesser levels of compliance (Single-A) should be mandated (P1), while higher levels (Double and Triple-A) recommended (P2 and P3).

[Guideline 7]

This section describes three (3) separate modes of content navigation. Sequential in which content is advanced line by line with link choices made active as they appear (and deactivated as they disappear) within the context of other content on the page; Direct in which content is bypassed by specifying some selection criteria that if met directs the focus of the viewport directly to the desired content or link; and finally Structured wherein important structural items (headers, titles, etc) are presented without the corresponding intervening non-structural content.

In point of fact, there is actually a fourth mode possible, which could be described as "Oriented-Direct" in which content and links are rendered sequentially in-context, but links are available for direct access to web resources at any time, (i.e. during, after) even immediately prior to content rendering. This navigation mode has the added benefits of context, speed and complete content availability, not offered by the other three modes taken on an individual basis.

In some cases, it may be desirable to navigate content without being prompted for the selection of active links, in order to quickly examine a page. In support of this "quick review" capability, an additional navigating mode, "content only" should be added to the description of navigating mechanisms just prior to the checkpoints for this section:

"User agents should allow users to configure navigation mechanisms (e.g., to allow navigation of links only, or links and headings, content only, or tables and forms, etc.)."

[Checkpoint 10.5]

This Priority 2 checkpoint recommends documenting changes in user agent and/or assistive technology software, as a result of software upgrades, that affect accessibility. This seems to be at least as significant as documenting accessibility features (checkpoint 10.2) which has been given a Priority 1 ranking.

Undisclosed changes in accessibility feature availability and or operation as a result of software upgrades can be disorienting to a user that has become accustom to certain feature behavior. For this reason, I would recommend raising this checkpoint to Priority 1 status.

[4. Glossary]

In the description for this term it is stated that "If the image is part of a link and understanding the image is crucial to guessing the link target, then the equivalent must also give users an idea of the link target. Thus, an equivalent is provided to fulfill the same function as the equivalency target.". While true, it should be remembered, and possibly noted in the definition since this document applies to user agents that only the content author can determine absolutely the equivalent for a given equivalency target.

To take the "full moon" example found within this definition:

If an image of a full moon exists in the content, there is no method, short of complex image analysis, for a user-agent to determine on it's own that the image should be described as a "full moon", "harvest moon" or "white disk".

A typo exists in the next to last sentence in the definition:

"Some user preferences may change content, such as when the user has turned off support for images and a placeholder icon [to] appears in place of each image that has not been loaded."

The suggestion that selected content should be rendered as "inflected speech" by a speech synthesis system is somewhat questionable. Speech inflection occurs many times within normal speech and in addition, what constitutes inflection is neither speaker nor listener independent. In other words, what one listener feels is inflected speech may seem normal to another listener and vice-versa. There may be no reliable method of conveying selected content when human speech is involved, other than possibly volume changes or marker tones, the latter being fairly common.

A typo exists in the third sentence of the definition:

"For example, [the] Web content developer can ensure that the segments of caption text are neither too long nor too short, ….. "

An apparent typo exists at the end of the second paragraph in the definition:

" … that the individuals in the groups are not required to have specialized skills (e.g., computer science degree), etc.".

Perhaps what was intended was:

" … that the individuals in the groups are not required to have specialized skills (e.g. computer science degree, etc.).

-end-