W3C home > Mailing lists > Public > w3c-wai-au@w3.org > July to September 1999

Comments on Last Call AUGL

From: Ian Jacobs <ij@w3.org>
Date: Tue, 07 Sep 1999 00:17:37 -0400
Message-ID: <37D491E1.2CB7D396@w3.org>
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:


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

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


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:
       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.

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):

       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.

   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

        For instance, authors will benefit from 
        a structured view of the document that
        provides an overview of the contents
        and facilitates their navigation.

   6.c) Checkpoint 7.2: In comment afterwards,
        delete "their" and the comma after

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

  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>

  7.e) Accessibility Solution. Don't capitalize
       "Authoring" in "Authoring practices".

8) References

  8.a) Put a cmoma after McCathieNevile in 


 - 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:43 UTC