- From: Ian Jacobs <ij@w3.org>
- Date: Fri, 08 Jan 1999 16:14:43 -0500
- To: Jutta Treviranus <jutta.treviranus@utoronto.ca>
- CC: w3c-wai-au@w3.org
Jutta Treviranus wrote:
>
> There is a revised AU working draft at:
> http://www.w3.org/WAI/AU/WD-WAI-AUTOOLS-19990101.html
>
> The list of changes can be viewed at:
> http://www.w3.org/WAI/AU/changes.html
Here are a few comments on the latest draft.
- Ian
GENERAL COMMENTS
- Table of Contents
I don't think the priorities should be listed in the TOC.
Perhaps they will "disappear" if it turns out that the
guidelines aren't prioritized (now the case with the
Page Author and User Agent guidelines)
- "Techniques" in the guidelines document should be replaced
by "checkpoints" (the change was intended for Jutta in fact!).
- All checkpoints should be expressed using the same grammatic
form (whatever that is). For instance, if the imperative voice
is chosen, they should all start with "Ensure" or "Allow" or
"Implement" or whatever. Today, the language used to express
the checkpoints varies greatly from checkpoint to checkpoint
- Checkpoints should not contain rationales. Thus, for instance,
for 2.10.1, the rationale part: "In order to ensure
that documents are made accessible according to the WAI Page
Author Guidelines" should be stated elsewhere, for example,
before the checkpoints in section 2.10. Checkpoint 2.10.1
should be reduced to: "Include an automated tool that identifies
and helps correct accessibility problems"
- Some of the checkpoints contain "too much information" and should
be broken down into several checkpoints. As an editor, I can
understand the urge to combine similar checkpoints. However, the
UA WG has expressly asked for simpler statements that may be
checked individually rather than compound checkpoints.
- Like the other guidelines, this document needs an introduction
that explains how the guidelines are to be used. I hope to
write an introduction (soon) that may be used with few modifications
in all three guidelines.
- I think many of the Priority 1's are too strong for the
content of the checkpoints.
SPECIFIC COMMENTS
2) Ensure that content produced by the tool is accessible
- In the first guiding principle, change "to free authors to"
to "so that authors may"
- Rewrite the second guiding principle as follows:
"Once accessibility is integrated into authoring tools,
authors will be much more likely to produce accessible documents."
2.1) In the first sentence, change "Authoring tools should" to
"Authoring tools must" since this is a Priority 1.
2.2) Support all accessible content recommendations.
While the title speaks of "content", the prose in the section
speaks of "markup". Choose one, probably "content" since
images might be involved.
- Checkpoint 2.3.1 : The text is too vague. What does "most accessible
mean"? Perhaps this should be a guideline.
- Checkpoint 2.3.2 : What does "user input is ambiguous" mean?. This
text is also so vague that I think it's more of a guideline
or introductory prose
2.4) "Note. the therm checking below does not necessarily ...."
This note is out of context since we don't know yet know
enough about the difference is between checking and alerting.
- Checkpoint 2.5.2 : Too much info in this technique. Break it up.
- Checkpoint 2.5.3: Separate into two: one for video, one for audio.
- Checkpoint 2.6.1: Too much info. Break it up. The last sentence
belongs in the (future) techniques document.
- Checkpoint 2.6.2: This is not a checkpoint but a real technique
that belongs in the techniques document.
- Checkpoint 2.6.3: Same as 2.6.2
- Checkpoint 2.7.1: Lots of rationale text that belongs in the paragraph
before the checkpoints.
- Checkpoint 2.7.3: First part is rationale: "Increate user acceptance
of pre-written ..." This should not be in the checkpoint.
- Checkpoint 2.10.1: The first part of the sentence is rationale
and should be moved. Reduce this to "Include an automated
tool that identifies and helps correct accessibility problems."
Note that "identify" and "help correct" are very different
issues and this and similar checkpoints should be divided
accordingly.
- Checkpoint 2.10.2: Change "The correcting tool must be
designed in such a way that authors can correct" to "Allow
authors to correct"
- Checkpoint 2.11.2: Delete. This one amounts to "Authoring
tools must produce accessible markup" which is the point
of the guidelines. I don't think talking about "algorithms"
changes anything (and is only about implementation).
- Checkpoint 3.2.1: Move the rationale elsewhere
- Checkpoint 3.2.2: Change the wording to use the imperative voice.
- Checkpoint 3.4.2: This is not a checkpoint but a technique that
is one good idea related to 3.4.1. This belongs in the
techniques document.
- Checkpoint 4.1.2: Too much rationale. Move elsewhere. Rephrase
the technique as "Emphasize universal design principles in
help text."
--
Ian Jacobs (jacobs@w3.org)
Tel/Fax: (212) 684-1814
http://www.w3.org/People/Jacobs
Received on Friday, 8 January 1999 16:15:10 UTC