comments on working draft

Here are some comments on the working draft, both typographic
and substantive.
Referring to document at:
http://www.w3.org/WAI/UA/WAI-USERAGENT-19990716

My comments marked by MR:.

-Madeleine

MR: General comments: I support the suggestion that we arrange the
guidelines in roughly order of importance. I would vote to place
11 and 12 (W3C technologies and OS conventions) nearer the top
and 6 (document styles), 9 (orientation) and 10 (notify of changes)
toward the end, for example. But 1 and 2 probably belong in sequence,
despite any difference in importance, and there may be other logical
orders that should be preserved.

MR: In section 1.1 on principles of accessible design it says that
the guidelines fall into 4 categories (access to interface, access
to content, orientation, and system standards) but those categories
are not tied to specific guidelines. Would it make sense to do that?
Could be either by grouping the guidelines in four groups, or by
listing in section 1.1 which guidelines support which principle.
If we did organize the guidelines by those categories, we'd lose
the "order of importance" option, for the most part.
 
Abstract 
Some browsers or multimedia tools may not support some of the
features described in the guidelines. In particular, new
features of HTML 4.0 or CSS 1 or CSS 2 may not be supported.

MR: Is this leftover from the WCAG document? For UA we want to
encourage support of these new features, so this sentence seems
out of place.

2. How the Guidelines are Organized
The checkpoint definitions in each guideline explain how the 
guideline applies in typical content development scenarios.

MR: this probably came from the WCAG document? How about:
The checkpoint definitions in each guideline explain how
the guideline applies in typical user agent usage scenarios.

(bullet) A link to a section of the Techniques Document
([UA-TECHNIQUES]) where implementations and examples of the
checkpoint are discussed. 

MR: Actually, it's a link to an index that then refers you to
the section where the implementations and examples are discussed.
I had trouble figuring this out. I kept thinking that these
techniques hadn't been written yet, not realizing I had to follow
a second link to the "refer to" section. I see now how this was
done, and that it is also what was done for WCAG, but I think
it could be clearer.

MR: Was the index built to support cases where a checkpoint is related
to more than one part of the techniques? Currently only 4 of the
checkpoints have more than one reference, making this link to the
index an annoyance rather than a help in most cases. (Though
I understand that may change as the techniques document matures.)
Or is the index needed so that the Guidelines doc can be stable
while the techniques doc changes? In that case, let's just 
clarify the language. Perhaps in the Techniques index we could
change the words "Refer to" to "Techniques are in section." And in
the bulleted item in the Guidelines document, should we mention
this index?

Guideline 1 rationale on input and output device independence

MR: My understanding is that most alternative input devices use
either the keyboard or the mouse input channels to communicate
with the operating system. I suggest adding a sentence that says
something like this and urges UAs to use only the OS standard ways
of reading the input channels. This might clarify the statement
that UAs need not support every input device since they will most
likely do so transparently by appropriately supporting the standard
devices. This might sound like a technique, but I think it is
important to include this info for developers who might be surprised
by the long list of alternate input devices. (This is closely
related to the Guideline 2 rationale, but since most readers will
read GL 1 first, can we clarify here?)

MR: Could add a sentence after the example of input about output
device independence such as:
"And any output provided in audio should also be available in
text since most alternative output mechanisms rely on the presence
of system-drawn text on the screen."

Checkpoint 2.6 Indicate the keyboard access method to activate a
user agent function using platform conventions. [Priority 2] 

JRG: Does checkpoint 2.6 currently only refer to how to activate an
author supplied ACCESSKEY binding to a link or a control? If it is
only related to ACCESSKEY, then maybe it should be stated for
ACCESSKEY in the checkpoint.  Otherwise I am not sure how it is
different from checkpoints 2.2 and 2.3

MR: I understood this to refer to UA interface functionality,
like menus and dialog boxes, and to mean "Underline the quick
access letter on Windows, and do whatever the current platform
usually does in other platforms." Perhaps an example note would
clarify, or the technique will once it is written.

Checkpoint 3.1 Ensure that all product documentation conforms to the
Web Content Accessibility Guidelines. [Priority 1] 

MR: Should this say "all electronic product documentation"? The 
technique goes as far as "Documentation created in HTML" but
the checkpoint wording seems to include paper as well, which the
WCAG won't have much help for. The WCAG has basic principles which
apply to non-HTML docs, so maybe techniques should say "Use WCAG for
docs in HTML, and observe the same principles as well as relevant
interface checkpoints in this document when using other technologies."

Guideline 5: User agents are only expected to provide this control
for content that it recognizes.

MR: Should be "that they recognize."

(bullet) The document's content. This means whether primary content
or alternative representations of content or both are rendered. 

MR: for consistency with previous bullet, change to:
The document's content: whether primary content
or alternative representations of content or both are rendered.

Otherwise, users who are blind, have visual impairments, some types
of learning disabilities, or any user who cannot or has chosen not to
view the primary representation of information will not know content
of the information on the page. 

MR: suggest minor edits to:
Otherwise, users who are blind, have visual impairments, or have some
types of learning disabilities, or any user who cannot or has chosen not
to view the primary representation of information, will not know the
content of the information on the page.

MR: I propose adding a new checkpoint (between current 5.5 and 5.6)
"Allow the user to turn on and off rendering of audio descriptions.
[Priority 1]"

Guideline 6: Ensure that the user has control over the colors, fonts
and other stylistic aspects of a document and can author styles and
user agent default styles. 

MR: Add the word "override" before "author styles."
(It would also be nice if the UA supported the user authoring styles.
But I think that comes in the configuration checkpoints (smile).)

Checkpoint 6.8 Allow the user to control video frame rates. [Priority 1]

MR: Apologies if I missed discussion on this (can't find any in this
year's mailing list archives). Why do users want to control video
frame rates? If what is meant is that users want to speed up and slow
down video to improve comprehension or save time, say that. Changing
frame rate changes the quality of video but may not effect how fast
content goes by. The only access issue I'm aware of for frame rates is
that sign language requires high frame rates to be comprehensible, but
that is an authoring issue and a bandwidth issue, I think.

Checkpoint 7.6: If a technology allows for more than one caption or
description track for audio, allow the user to choose from among tracks.
and
Checkpoint 7.7 Allow the user to specify that captions for audio be
rendered at the same time as the audio. 

MR: Remove "or description" from 7.6. Audio tracks do not get
description tracks. Also, I suggest swapping the order of 7.7 and 7.6,
since rendering at the same time is the most basic thing to be done,
and switching tracks is an add-on. (I do think it is priority 1, just
slightly below getting the synchronization right.)

Checkpoint 7.8 If a technology allows for more than one caption or
description track (e.g., text, video of sign language, etc.) for
video, allow the user to choose from among tracks.
and
Checkpoint 7.9 If a technology allows for more than one audio track
for video, allow the user to choose from among tracks.

MR: I'm not clear on the difference between these two. If the intent
was to separate captioning checkpoints from description checkpoints,
remove "or description" from 7.8 and perhaps add "or video"
to cover the idea of ASL tracks. Then clarify that the audio tracks
referred to in 7.9 may be description.

MR: Or is 7.9 meant to refer to alternate languages, or some other
kind of non-description alternate audio like director's comments?
If so, is that an access issue? (That is, if the UA supports changing
languages or hearing the director's comments, that feature must be
accessible, but that should be covered by the checkpoints on interface
accessibility.)

Checkpoint 7.10 Allow the user to specify that text descriptions of
video be rendered at the same time as the video. [Priority 1] 
and
Checkpoint 7.11 Allow the user to specify that auditory descriptions
of video be rendered at the same time as the video.

MR: Could 7.10 and 7.11 be combined with "and" or "or" ("text and 
auditory descriptions")? Also, as mentioned for 7.6 and 7.7, I
suggest reordering so that the checkpoints on rendering at the
same time (7.10 and 7.11) come before the ones on extra tracks
(7.8 and 7.9).

Guideline 12: When a user agent communicates with other software
(dependent user agents, the operating system, plug-ins), must do so
through applicable interfaces.

MR: add "it" before "must."

Checkpoint 12.4 For desktop graphical browsers. Comply with W3C
Document Object Model specifications and export interfaces defined
by those specifications.

MR: Should this be part of Guideline 11 on W3C technologies rather
than in this section on operating system conventions? Or is it here
because we are asking that UAs export the DOM into an operating
system standard interface? If so that could be clearer.

Techniques document
2.1 Examples and Deprecated Examples
This document contains a number of examples that illustrate accessible
solutions in HTML, CSS, etc. but also deprecated examples that
illustrate what content developers should not do.

MR: Left over from WCAG? There aren't currently any deprecated
examples in the techniques, though I know it isn't done yet. At
any rate, they won't be illustrations for content developers.

3.8.1
These profiles can serve as models and may be copied and fine-tuned
to mean an individual's particular needs. 

MR: change "mean" to "meet."

3.9.2
Accessing documentation in familiar applications is particularly
important to users with disabilities who must learn the
functionalities of their tools, be able to configure them for their
needs, and to be compatible with assistive technology.

MR: suggest change to:
Accessing documentation in familiar applications is particularly
important to users with disabilities who must learn the
functionalities of their tools and be able to configure them for
their needs. Commonly used applications are also more likely to be
compatible with assistive technology.

Documents in alternative format documents can be created by agencies
such as Recording for the Blind and Dyslexic and the National Braille
Press.

MR: Remove second "documents", change "format" to "formats." Or start
sentence with "Alternative."

User instructions should be created in an input device-independent manner.

MR: suggest changing "created" to "worded" or "expressed."

4.4 The document object model
MR: The current technique text talks more about what DOM can't do than
about what it can do. Would be helpful to have concrete examples of
useful DOM features. Unfortunately I don't know enough about DOM to
suggest them myself. The text about what DOM can't do could possibly
say, "The DOM can't do some things, therefore see the techniques in
the sections on user interface to ensure style and scripting
controls are accessible" rather than insert info on accessible 
controls in this section.

Section 7 SMIL accessibility
MR: I can work on techniques for multimedia accessibility sections.
One question is, can the UA techniques document be more forward looking
than current W3C recommendations? The SMIL access note being written by EO
refers only to SMIL 1.0, but SMIL 2.0 is in development and may include
additional features. Can we use the UA recommendations to encourage
player developers to advance the state of the art?

MR: If section 7 will primarily point to the SMIL access document,
which sections would be best for specific techniques? 3.3, User
Control of Style? 3.3.1 Feature Control?

MR: Also, should we discuss techniques for other streaming media types
(AVI, QuickTime)? NCAM has lots of info on this stuff so if you give me
some pointers on how you'd like it structured I can pull something
together for the group to look at.

Section 9, part on Example Technique: Java's Direct Access
In Java 1.1.x, Sun's Java access utilities load an assistive by
monitoring the Java awt.properties file for the presence of assistive
technologies and loads them as shown in the folowing code example:

MR: typo, should be "following."

--end of MR comments--

Received on Thursday, 5 August 1999 17:13:18 UTC