Comments on 10 March Version of the UA Techniques Document

Date: 25 April 2000, 11:15 hrs
To: UA List (w3c-wai-ua@w3.org)
From: Eric Hansen
Re: Comments on 10 March Version of the UA Techniques Document

This memo documents some comments regarding the 10 March 2000 version of the
UA Techniques document. Many of the comments also apply to the UA Guidelines
document. The hardcopy for a bunch of small edits is being mailed to Ian
Jacobs and Jon Gunderson.

Most, if not all of these comments are, I believe, editorial in nature.

1. Clarify the need for outputting the entire content through at least three
modalities -- visually-displayed text, synthesized speech, and Braille.

It seems to me that the document needs to make clearer that a UAAG-compliant
User Agent that is accessing WCAG-compliant content will be able to render
all Web content through each of at least three modalities --
visually-displayed text, synthesized speech, and Braille -- subject, of
course, to the limitations the applicability provisions of UAAG.

Checkpoint 1.1 requires that every functionality available through the user
interface also be available through every _input_ device API supported by
the user agent (emphasis added). But what about "_output_ modalities? I can
understand that one may not want to require that all content be available
from _each_ output _device_ (speakers, beep-producing device, etc.).
Technically speaking, perhaps what is needed is already covered by
checkpoint 1.2 ("Use the standard input and output device APIs of the
operating system." [Priority 1]). But the necessity of having all content
available in each of the three channels seems to be underemphasized. I think
that should be added somewhere.

2. Provide better descriptions of visuals.

I believe visuals need to be better described. With the possible exception
of one visual (in Technique for checkpoint 8.6), I don't think we can say
that we are providing true text equivalents. Consider the following example.

OLD:

Prose description in main body of document: "The following image shows how
Opera [OPERA] allows the user to configure link rendering, including the
identification of visited links."

The alt-text, which shows up in the ToolTips window says: "The Opera dialog
box for configuring  links"

NEW: 

"Opera [OPERA] allows the user to configure link rendering. For example, as
shown in the image below, Opera provides a "Link Presentation" dialog box
that allows the user to configure attributes, such as how unvisited links
should be rendered (e.g., by underline, strike through, color) and how long
visited links will be marked as visited before reverting to an unvisited
status."

I suppose that the current alt-text is OK, provided that the primary text
mentions the dialog box (along the lines suggested above).

Rationale:

The picture is supposed to show "_how_ Opera allow the user to configure
link rendering". The minimal explanation of "how" must, at a minimum, make
reference to the "dialog box". Thus, if the "text equivalent" does not
mention the dialog box and say something useful about it, I don't think that
it can be considered a true text equivalent.

Virtually every image in the document needs a similar expansion. I believe
that to fail to do so would mislead people about what a text equivalent is.

3. Fix the definition of "Viewports".

Fix reference to content. Menus and message should not be excluded from the
definition of "content".

Old:

"Views, viewports, and current viewport
User agents may handle different types of content: a markup language, sound,
video, etc. The user views rendered content through a viewport, which may be
a window, a frame, a piece of paper, a speaker, a virtual magnifying glass,
etc. A viewport may contain another viewport (e.g., nested frames).
Viewports do not include user interface controls that do not present
content, such as prompts, menus, alerts, etc. 
User agents may render the same content in a variety of ways; each rendering
is called a view. For instance, a user agent may allow users to view an
entire document or just a list of the document's headers. These are two
different views of the document.
The view corresponds to how source information is rendered and the viewport
is where it is rendered. The viewport that contains both the current focus
and the current selection is called the current viewport. The current
viewport is generally highlighted when several viewports co-exist. 
A viewport may not give users access to all rendered content at once. In
this case, the user agent should provide a scrolling mechanism or advance
and rewind mechanism."

New:

"Views, viewports, and current viewport
User agents may handle different types of content: a markup language, sound,
video, etc. The user views rendered content through a viewport, which may be
a window, a frame, a piece of paper, a speaker, a virtual magnifying glass,
etc. A viewport may contain another viewport (e.g., nested frames).
<CHANGE>Viewports do not include user interface controls such as prompts,
menus, alerts, etc.</CHANGE> 
User agents may render the same content in a variety of ways; each rendering
is called a view. For instance, a user agent may allow users to view an
entire document or just a list of the document's headers. These are two
different views of the document.
The view corresponds to how source information is rendered and the viewport
is where it is rendered. The viewport that contains both the current focus
and the current selection is called the current viewport. The current
viewport is generally highlighted when several viewports co-exist. 
A viewport may not give users access to all rendered content at once. In
this case, the user agent should provide a scrolling mechanism or advance
and rewind mechanism."

4. Use plain English rather than short symbolic titles when referring to
documents.

For the example in section 1.1 of the document, it reads: 

"... link to the checkpoint in [UAAG10]."

Instead it should read something like:

"... link to the checkpoint in the User Agent Accessibility Guidelines 1.0
[UAAG10]."

5. Make Technique statements parallel in construction.

For example, all Techniques within a checkpoint start should have a similar
construction, such as by starting with a verb.

6. Respect proprietary rights of regarding product and company names. 

For example, the document often uses the term "Windows" without referring to
Microsoft Windows. The document refers to Java without mentioning Sun.
Carefully distinguish between W3C DOM and just a generic DOM. Make sure the
term "zip" is generic or credit the owner. I think that W3C needs a policy
for referring to products and then the documents need to follow the policy.

7. Widen margins in text boxes.

Text within text boxes need wider margins. The text is too close to the
lines.

8. Fix dash problem.

For dashes that cannot be put into dash characters, use double hyphens in
preference to single hyphens.

9. Fix checkpoint 1.5.

I am unsure whether checkpoint 1.5 is needed in its present form. It seems
covered by other checkpoints. 

Also, the techniques seem to be imprecise about whether the text equivalent
that must be provided refers only to visually-displayed text or to other
renderings as well (Braille and synthesized speech). 

Sometimes in this checkpoint, the term text equivalent seems to be referring
to unrendered content and other times to rendered content, in which case it
may be important to make clear what renderings are intended.

The following attempts to clarify, though it seems as yet imperfect.

Also I am not sure why it is limited to "messages". Why not all content?

Old: 

"1.5 Ensure every non-text message (e.g., prompt, alert, etc.) available
through the user interface also has a text equivalent in the user interface.
[Priority 1] (Checkpoint 1.5) 
Note. For example, if the user interface provides access to a functionality
through a graphical button, ensure that the user interface also provides
access to the same functionality through a control that includes a text
equivalent. If a sound is used to notify the user of an event, announce the
event in text on the status bar as well. Refer also to checkpoint 5.7. 
Techniques:
Display text messages on the status bar of the user interface. 
For graphical user interface elements such as proportional scroll bars,
provide a text equivalent (e.g., a percentage of the document viewed). 
Provide a text equivalent for beeps or flashes that are used to convey
information. 
Provide a text equivalent for audio user agent tutorials. Tutorials that use
speech to guide a user through the operation of the user agent should also
be available at the same time as graphical representations. 
All user interface components that convey important information using sound
should also provide alternate, parallel visual representation of the
information for individuals who are deaf, hard of hearing, or operating the
user agent in a noisy or silent environment where the use of sound is not
practical. 
Text equivalents of messages are important for deaf-blind users who cannot
use audio or graphical cues and who rely on Braille."

New: 

"1.5 Ensure every non-text element available through the user interface also
has a text equivalent in the user interface. [Priority 1] (Checkpoint 1.5) 
Note. For example, if the user interface provides access to a functionality
through a graphical button, ensure that the user interface also provides
access to the same functionality through a control that includes a text
equivalent <CHANGE>_that can be displayed visually, as synthesized speech,
or as Braille.</CHANGE>_  If a sound is used to notify the user of an event,
announce the event in text on the status bar as well. Refer also to
checkpoint 5.7. 
Techniques:
Display text messages <CHANGE>visually on the status bar of the user
interface. 
For graphical user interface elements such as proportional scroll bars,
provide a text equivalent (renderable visually, as synthesized speech, and
braille) (e.g., a percentage of the document viewed). 
For beeps or flashes provide a text equivalent that can be rendered as
Braille, synthesized speech, or visually-displayed text). 
Provide a text equivalent for audio user agent tutorials. Tutorials that use
speech to guide a user through the operation of the user agent should also
be available at the same time as graphical representations. {*** Note that
"tutorials" are certainly more than "messages". ***}
For user interface components that convey important information using sound,
also provide alternate, parallel visual representation of the information
for individuals who are deaf, hard of hearing, or operating the user agent
in a noisy or silent environment where the use of sound is not practical. 
Provide Braille renderings of text equivalents for deaf-blind users who
cannot use audio or graphical cues and who rely on Braille. </CHANGE>

====

10. Clarify the meaning of user interface.

I find the meaning of the term "user interface" somewhat ambiguous. I am not
sure that I fully understand or agree with the distinction between "user
agent user interface" (i.e., the controls and mechanisms offered by the user
agent for user interaction, such as menus, buttons, keyboard access, etc.)
and the "content user interface" (the "content user interface", i.e., the
active elements that are part of content, such as form controls, links,
applets, etc. that are implemented natively). 

I am not sure that there is anything wrong with the current definition. It
seems, in principle, open to all kinds of output devices (including Braille,
etc.) and input devices. But in actual usage in the document, the term user
interface seems to incorrectly assume that content is displayed visually or
as prerecorded audio but not as braille or synthesized speech. This makes
the term biased, as though there could not be Braille output.  I can't help
but feel that our discussion about text equivalents and output of content
via APIs-versus-user interface has been somewhat impaired by lack of clarity
regarding the meaning of "user interface." 

I would be interested in seeing if a user interface might be more formally
extended to relate better to other concepts in the UA document (e.g., views,
primary content, unrendered-vs-rendered content, etc.). 

This is a bit vague and maybe there is nothing to do about it now...

11. Fix the definition of "content".

Fix the definition of content. I know that some modification has been made.
Hopefully, the improvements will rub off on some of the foregoing issues
(user interface, viewports, checkpoint 1.5).



===========================
Eric G. Hansen, Ph.D.
Development Scientist
Educational Testing Service
ETS 12-R
Princeton, NJ 08541
609-734-5615 (Voice)
E-mail: ehansen@ets.org
(W) 609-734-5615 (Voice)
FAX 609-734-1090

Received on Tuesday, 25 April 2000 11:20:54 UTC