Comments from Prof. Constantine Stephanidis

Last Call review of
User Agent Accessibility Guidelines 1.0

Prof. Constantine Stephanidis

Institute of Computer Science
Foundation for Research and Technology - Hellas
&
Computer Science Department
University of Crete


1. Introduction
The review comments herein concern the "User Agent Accessibility Guidelines 
1.0" (UAAG 1.0) last call Working Draft, available from:
http://www.w3.org/TR/2000/WD-UAAG10-20001023/

The comments are separated into two categories: (a) general comments 
regarding the overall state of UAAG 1.0, and (b) comments to specific 
sections / guidelines within UAAG 1.0.

In general, UAAG 1.0 constitute a major improvement over the previous 
version. Congratulations to all the people whose hard work has made this 
possible. It is understood that the issues raised in section 2 "General 
comments" below, may be difficult or impossible to address in the current 
version of the Guidelines. However, they should probably be considered as 
priority items for the next version. In contrast, section 3 "Specific 
comments" below addresses issues that could and probably should be 
addressed within the current version of the UAAG.

2. General comments
An important issue regarding the UAAG 1.0 as a whole, concerns the 
underlying assumption that accessibility in a primary User Agent is mainly 
attained through cooperation of that User Agent with secondary User Agents, 
or with assistive technologies. In fact, many Checkpoints at Priority Level 
1 (e.g., some of the Checkpoints in Guideline 5) assume that this is indeed 
the approach that a User Agent developer would take. Complying with all 
these Checkpoints may be unnecessary if a an "ideal" User Agent can be 
developed that is Universally Accessible (i.e., accessible by "all" 
potential user categories) for a particular type of content. It is conceded 
that, even in that case, complying with these Checkpoints may still be 
possible. However, at the same time, it may be undesirable and burdensome 
(especially if novel approaches to accessibility are employed, not based on 
'off-screen model' and its descendant approaches). With the current state 
of the UAAG, such an "ideal" User Agent may not even reach Level A 
conformance, although it would, at lest in theory, be fully accessible.

Another important issue that is not covered explicitly by the UAAG 1.0 
concerns the behavior of User Agents when encountered with content that is 
device-dependent by nature. Consider the example of HTML and scripts that 
are executed upon mouse events (e.g., a script may be triggered as a result 
of a 'mouseover'). For users that do not employ a mouse (or equivalent 
pointing device), it would be impossible to activate that script, unless:
* the User Agent notified users of the presence of such 'event handlers' 
and, additionally, enabled users to navigate (at least sequentially) 
through them;
* the User Agent enabled users to 'manually' trigger such event handlers, 
and notified users of the results that triggering has effected to the document.

Although cases such as the above example fall implicitly (in my opinion) 
under Checkpoint 1.4 ("Ensure that the user can interact with all active 
elements in a device-independent manner."), it may be worthwhile to 
explicitly address this issue through a 'special case' Checkpoint, or, at 
least, through a clarifying Note within the existing text.

3. Specific comments
3.1. Guideline 1 - Rationale
The document states: "Since people use a variety of devices for input and 
output, user agent developers must ensure redundancy in the user interface. 
Th[e] user must be able to operate the user interface with a variety of 
input devices (mouse, keyboard, speech input, etc.) and output devices 
(graphical display, speech output, braille display, etc.). The user must 
also have access to the full benefit of Web content through each of at 
least three modalities -- visually-displayed text, synthesized speech, and 
braille."

The above wording is open to the interpretation that the User Agent 
developer is responsible for supporting "alternative" input and output 
modalities and devices. The situation is somewhat clarified within 
Checkpoint 1.1, where it is stated that "This checkpoint does not require 
developers to implement all operating system input APIs, only to make the 
software accessible through those they do implement." However, a 
clarification may be in order (in the Guideline rationale) to avoid any 
confusion.

3.2. Guideline 1 - Checkpoint 1.3
Checkpoint 1.3 requires User Agent developers to "Implement the operating 
system's standard API for the keyboard and ensure that every functionality 
available through the user interface is available through this API."

Introducing this Checkpoint at Priority Level 1 precludes the possibility 
of developing User Agents that are intended to provide custom accessibility 
solutions, not based on keyboard input (or on the desktop metaphor, for 
that matter). Consider, for example, the case of a customized accessible 
User Agent, available at a public information point (e.g., on a kiosk). If 
this User Agent was to employ a joystick as the sole input device for its 
users (including, for instance, sighted and blind people), there might be 
no reason for implementing the keyboard API of whatever operating system it 
is running on. In this example, the User Agent might render itself, as well 
as content attained through it, perfectly accessible (in terms of both 
presentation and interaction) to its target users. However, the User Agent 
would never reach Level A compliance with UAAG 1.0, because of Checkpoint 
1.3. Is this the intended case?

3.3. Guideline 2 - Checkpoint 2.7
Checkpoint 2.7 requires User Agent developers to "Allow the user to 
configure the user agent not to render content marked up in a recognized 
but unsupported natural language."

For completeness, the above sentence could be rephrased as: "Allow the user 
to configure the user agent not to render content marked up in an 
unrecognized, or a recognized but unsupported natural language."

3.4. Guideline 5
Please refer to section 2 "General comments" above.

3.5. Guideline 6 - Checkpoint 6.1
Consider making this checkpoint "scalable" by introducing three Priority 
Levels for this Checkpoint, matching Conformance Level A, Double A and 
Triple A of the WCAG. This would most probably result in increased 
flexibility in the implementation of this Checkpoint and would allow for 
phased developments of progressively increased conformance.

3.6. Guideline 9 - Checkpoints 9.1 and 9.3
Consider raising the Priority Level of these Checkpoints, as lack of 
support for them may be a major obstacle to content accessibility for 
different categories of users. Specifically, it is suggested that 
Checkpoint 9.1 is raised to Priority Level 1 and Checkpoint 9.3 is raised 
to Priority Level 2.
	
Jon Gunderson, Ph.D., ATP
Coordinator of Assistive Communication and Information Technology
Division of Rehabilitation - Education Services
MC-574
College of Applied Life Studies
University of Illinois at Urbana/Champaign
1207 S. Oak Street, Champaign, IL  61820

Voice: (217) 244-5870
Fax: (217) 333-0248

E-mail: jongund@uiuc.edu

WWW: http://www.staff.uiuc.edu/~jongund
WWW: http://www.w3.org/wai/ua

Received on Tuesday, 21 November 2000 10:18:05 UTC