- From: Ian Jacobs <ij@w3.org>
- Date: Tue, 07 Sep 1999 00:17:37 -0400
- To: w3c-wai-au@w3.org
Hi folks,
Great work on the AUGL everyone!
My comments on [1] are primarily editorial.
First, the more substantial ones:
Non-editorial:
1) The rationale text at the end of Guideline 1
ends on a warning of what bad may happen.
I recommend adding a sentence to indicate how
to handle this situation. (No proposal yet.)
2) Checkpoint 1.1: Propose changing the word
"implement" to "carry out" or something else since
implement sounds like coding to me.
3) Checkpoint 2.2: Propose changing beginning
from "Ensure that markup is generated"
to "Generate markup". There are other checkpoints
(e.g., 3.1) in which the imperative verb
refers to what the tool should do (and not just
what the tool designer should do).
4) Checkpoint 2.3: Propose changing beginning
from "Ensure the tool produces" to "Produce".
What about changing it to "Produce
content in a markup language that enables
accessibility"?
5) Checkpoint 3.2: Remove the examples from the
checkpoint text and put them in the comment that
follows. They make the checkpoint text difficult
to read.
6) Move the note at the end of Guideline 4 rationale
to Guideline 2. It concerns valid markup, which
is addressed by checkpoint 2.2
7) Checkpoints 5.1/5.2:
I think they should only be priority 2. I think
that they are important to accessibility, but
not essential.
8) Checkpoint 7.3: I don't understand this checkpoint.
"Render an accessible equivalent of each
element property." Could this be restated
as "Ensure that each element's properties
are accessible."?
9) Definition of "Transformation". Why does the
definition include "equivalent"? That seems
incorrect to me. It may be equivalent, but
doesn't have to be.
10) Definition of "Transformation". The definition
says that Transformation also describes the
Substitution of textual equivalents. I'd prefer
using the term "Substitution" here instead of
"Transformation".
Editorial:
0) Global
0.a) Ensure that checkpoints end with one period. Some
end with zero, others with two.
0.b) Ensure that "Web site" is two words
0.c) Capitalize "Techniques Document".
0.d) Change "meet a checkpoint" to "satisfy a checkpoint".
0.e) Capital D in "Double-A". Capital T in "Triple-A".
0.f) Capitalize "R" in W3C Recommendation.
1) Header
1.a) Need space between month and year
2) Introduction (Section 1.)
2.a) May need to define WYSIWYG somewhere.
2.b) Fifth bullet: change to "tools that generate
Web sites dynamically..."
2.c) Change "Thus the goals of this document can
be stated as follows" to "Thus, the goals
of this document are:"
2.d) "This document provides guidelines for
designing authoring tools..." I think that
"This document" is ambiguous and should be
changed to "The present document".
2.e) The term "checkpoint" appears in the introduction
but has not been defined yet. I propose changing
occurrences of "checkpoint" to "guideline" in
the Intro. The term "guideline", though not defined
yet, is used comfortably beforehand.
3) How the Guidelines are organized. (section 1.1)
3.a) Remove the period from the heading itself
3.b) "This document includes guidelines which". Put
a comma after guidelines.
3.c) Change "meet a checkpoint" to "satisfy a checkpoint"
3.d) Proposed change to penultimate paragrahp in 1.1:
<BLOCKQUOTE>
The Techniques Document suggests implementation
strategies and includes references to pertinent
guidelines and specifications. The techniques
in that document are informative only and not
exclusive of other strategies that may
also satisfy the checkpoints.
</BLOCKQUOTE>
4) Checkpoint priorities (Section 1.2)
4.a) Put a period after the three numbered list items.
5) Guideline 3
5.a) The last sentence is too long. Propose rewriting
as follows (starting with "Where" in the
original text):
<BLOCKQUOTE>
Tools should determine this type of information
mechanically where possible (e.g., ...). They
should suggest this information to the author but
allow the author to edit or change it in order
to guarantee its applicability. This type of prompt
will facilitate authoring and remind the author
of the importance of equivalent information.
</BLOCKQUOTE>
5.b) Checkpoint 3.4: Remove comma after "objects".
6) Guideline 7
6.a) Put a comma after "In order to edit a document"
(third paragraph).
6.b) Propose rewrite to last sentence of the
rationale (which seems unclear and unduly
passive):
<BLOCKQUOTE>
For instance, authors will benefit from
a structured view of the document that
provides an overview of the contents
and facilitates their navigation.
</BLOCKQUOTE>
6.c) Checkpoint 7.2: In comment afterwards,
delete "their" and the comma after
"requirements".
7) Terms and definitions.
7.a) Prompts. The terms "author" and "user" are
both used and that may be confusing.
7.b) Authoring Tool. Section "1.3" no longer
exists.
7.c) Accessible/Accessibility. Put those two
terms in quotes in the definition.
7.d) Some (but not all) of the "DD" elements in this
DL list are followed by blank lines in the
printed version. Remove extraneous <P> or <BR>
elements.
7.e) Accessibility Solution. Don't capitalize
"Authoring" in "Authoring practices".
8) References
8.a) Put a cmoma after McCathieNevile in
[WAI-AUTOOLS-TECH].
Cheers,
- Ian
P.S. Comments on Techniques to follow...
[1] http://www.w3.org/TR/1999/WAI-AUTOOLS-19990903
Received on Tuesday, 7 September 1999 00:17:49 UTC