- From: Daniel Dardailler <danield@w3.org>
- Date: Wed, 06 Oct 1999 16:42:02 +0200
- To: w3c-wai-au@w3.org
Status section: I suggest changing the last sentence: A list of the current AU Working Group members is available. into A list of the curent AU Working Group members is available off the AU Home page and the _Acknowledgement section_ at the end of this document lists all the contributors to this specification. Beside the addition of the ackno pointer, it's important in both cases to mention where is the data in words (e.g. at the end of the file) because spec are often read on paper with complete loss of hyperlink indication (not to mention linking functionality of course). 1.2 Checkpoint priorities please change the OL into a UL. It's confusing to see the 1,2,3 "construct" mentioned twice: once for the goals and another time for real priority semantics. It also give a false indication of the priority of the goals. Same section: I suggest removing the justification Note about conformance level being spelled out and why: we're not stating a guideline for other to apply, are we ? Next paragraph: Form 1: I know we haven't done it for the WCAG, but I'd prefer if the guidelines title started with "W3C's Authoring.." Guideline 2: I have a hard time understanding "where applicable" (which is not defined). Consider a tool that generate Latex or some proprietary Math format. Are we saying this tool cannot be compliant with our spec ? I guess so: it's not using HTML or MathML. But why do we care: it's just not a web authoring tool, it's a authoring tool. Are we trying to say that tool that generate non W3C format should start doing so ? Also, I think we're missing the "Provide ways to indentify what extensions to W3C formats are being generated" as a checkpoint. Note that we still have "user configurable scheduled" in the glossary. Guideline 3: The last sentence of second paragraph ("Where such information...") doesn't make sense to me. Cut it in two maybe. The note in 3.2 : This text should be used for input field I think this applie sonly for image, not for video, etc, so this shoudl be mentioned. Guideline 4 I don't see the checkpoint related to providing way for the author to decide when the checking and repair happen. I think we should rename the guideline "Provide flexible/configurable methods of checking.." and we hsould have a new checkpoint saying that the tool should always let the user/author decide when to do the checking (either continuously, at some point, on save, on load, etc) 4.3: I think the 2nd point of the note is useless sine we don't talk about default setting anywhere in the guideline. Guideline 5: reorder to have P1 before P2 (here and in general, we should have a pass at reordering the checkpoint within the guidelines) Guideline 6: if I understand 6.2 correctly, it's about the inclusion of a specific seciton on accessibility in help, in addition to the spreading of the good word in all the regular sections (6.1) If yes, then it would be better to say: 6.2 Provide a specific accessibility section introducing the concept and the practices supported for the tool. I don't understand the note in 6.3 (and explaining it to me doesn't solve the issue - the document needs to change) Guideline 7: I proposed combining 7.3 and 7.4 into one checkpoint, same with 7.5 and 7.6. Just reword it to say: Allow the author to access and edit (all properties/the structure). Final comment: we should create a Priority WCAG, define it in the priority section and use it in various place where we inconsistently say "P1 if P1, P2 if P2, or P1 if A, P2 if AA, etc". The only issue is 7.1 which use (to add to the complexity) a similar but different scheme of "if priority". I suggest we remove the "all" in the text and make 7.1 a simple P1.
Received on Wednesday, 6 October 1999 10:42:07 UTC