- From: Charles McCathieNevile <charles@w3.org>
- Date: Tue, 14 Sep 1999 18:50:21 -0400 (EDT)
- To: Ian Jacobs <ij@w3.org>
- cc: w3c-wai-au@w3.org
my comments scattered, marked CMN - Ian's marked IJ On Tue, 14 Sep 1999, Ian Jacobs wrote: Hello, I haven't finished reading the AU techniques document that's part of last call [1] but I wanted to send these comments anyway. I will reserve most editorial comments for another review. 1) The document contains very little in the way of explanatory prose. This means that I think it will not help a reader unless that reader is a very informed developer. I think that this draft contains sufficient information for the Guidelines to become a Recommendation, but I think the Techniques document needs to be restructured with more prose, more explanations, and more rationale. CMN I agree that further explanations and rationale would be good. It would also perhaps provide a way of distinguishing the techniques document from the guidelines document. IJ 2) Under checkpoint 1.1: a) Bullet 1: Provide options for accessibility information such as equivalent alternatives to be included whenever an object is added to a document. I think the case of alternative text should be singled out. I think "such as" weakens a technique since the reader has no other place to turn at this point. There should be concrete examples in place of generalities. CMN I would prefer to provide a number of other alternatives, or to include (for example) the sections from teh sample implementations. In fact I would like those to be part of the general techniques as well as being available separately. IJ b) Bullets 3 and 4 refer to WCAG 1.0 Guidelines and Techniques. However, these are covered by checkpoint 1.2, so I suggest moving these techniques to checkpoint 1.2 c) I think techniques for W3C languages should be listed clearly, as in: * Accessibility of HTML * Accessibility of CSS * Accessibility of SMIL etc. The current wording obscures this. CMN I agree IJ 3) Under checkpoint 1.2 There should be no techniques in this checkpoint other than references to WCAG 1.0. I feel quite strongly about this since attempts to include information will necessarily be incomplete and risk deviating from WCAG 1.0. If the working group has suggested techniques, those should be sent to WCAG. CMN I am happy with that proposal IJ 4) Under checkpoint 1.3 a) Template is undefined in the checkpoint text. b) Please refer to "navigation mechanisms" instead of "navigation schemata" for consistency with other WAI Guidelines. CMN template is a commonly used word in English - I don't think it needs definition. Does somebody who does want to propose a definition? navigation mechanisms also sounds more consistent with the language that people actually use (grin) IJ 5) Under checkpoint 1.4 a) The second bullet talks about using "title" for descriptions of images. This is not recommended by WCAG. CMN I think this is a wordng issue. How about changing descriptions to associated text? IJ b) Fifth bullet: WYSIWYG is undefined. CMN Actually it is marked up in accordaance with WCAG. That issue should be referred to the WCAG group. IJ 6) Under checkpoint 2.1 a) (editorial) Text in the first bullet is repeated. 7) Under checkpoint 2.2 a) I think the checkpoint should read: "Ensure that generated markup conforms to a published specification." CMN Suits me. Thoughts anyone? IJ b) I don't understand the third bullet. It may mean: "Use schemas to describe transformations from one markup language to another." This may also be done with the XSL Transformation language. CMN Aaah. Another technique for the checkpoint. IJ 8) Under checkpoint 2.3 a) I don't understand the example about frames in the first bullet. It's not clear whether it means "Don't create a frame document with NOFRAMES" or "Don't use a DTD for frames without NOFRAMES". CMN It means the latter. Should it be reworded, or can someone provide a better example? IJ b) The third bullet should qualify that the statement applies to the time of publication of the AU Techniques Document. CMN We should list the trigger events which we expect to require changes to this document - change in status of anything to which we refer is such a trigger. IJ 9) Under checkpoint 3.1 a) What is the rationale of the second bullet on uppercase letters? CMN It is a clue for abreviations - we should make that explicit IJ b) Fifth bullet: say "natural language" CMN Yes IJ 10) Under checkpoint 3.2 a) In first bullet, say "alternative equivalents" instead of "alternative information". b) In the second bullet, say "image" instead of IMG and refer to a text equivalent instead of alt text. CMN I agree IJ 11) Under checkpoint 3.3 a) The second bullet on clip art long descriptions needs more explanation. CMN I agree. IJ b) In third bullet, refer to captions, not "video description files". CMN Why? The fourth bullet already does that. We can change the order if there is value in that... IJ c) In fifth bullet, there is reference to pre-written descriptions that will circulate on the Web. The same was said of shared style sheets and I don't think in reality that that is the case. I don't have any data to back up that statement, however. CMN TO the extent that style sheets are circulated (the only ones I know of are the W3C ones that I find referenced from time to time across the web) it does seem to do all the things suggested (I have worked with these as a private contractor for just that reason). IJ 12) Under checkpoint 3.4 a) The first bullet is too detailed and difficult to understand in its current wording. CMN I don't think so, although I would be happy to have a simplification, or a couple of diagrams indicating what was going on. IJ b) In the fourth bullet, there is reference to "alternative information mechanism" followed by the acronym "ACM". How do the two relate? Should it be AIM? CMN from the first use of the abbreviation: "...this alternative information mechansim (ACM) have the..." But I agree that AIM would seem like a more obvious abbreviation. This happened because we decided to use the term alternative information instead of alternative content and I missed making the change in the acronym - it is editorial. Charles McCN
Received on Tuesday, 14 September 1999 18:50:22 UTC