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

Re: New Draft: Please Review

From: Ian Jacobs <ij@w3.org>
Date: Fri, 08 Jan 1999 16:14:43 -0500
Message-ID: <36967543.49C7ACEB@w3.org>
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


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


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

- 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 
Received on Friday, 8 January 1999 16:15:10 UTC

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