- 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