Charles McCathieNevile, $Date: 1999/11/24 12:55:26 $
This document outlines the substantive comments included in the Member review of the Proposed Recommendation, and the results of the reviews in general terms. This document is intended for internal use by the members of the Authoring Tool Guidelines Working Group.
Note that during the proposed Recommendation period further comments were also received on the working group mailing list.
The complete list of issues raised during the Proposed Recommendation period, and their resolution, is available from the working group's issues list.
One reviewer (Member A) recommended the document be returned to the working group, and one reviewer (Member B) recommended it be published with minor changes.
One reviewer abstained.
The rest of the reviewers recommended the document be published as is, and around half reported that they intend to implement the guidelines. Further comments (given below) were also made by some of the members who recommended the guidelines be published as is.
No reviewers reported holding any Intellectual Property related to the Guidelines
We are very supportive of the goals of this document, and it is important to construe our comments as directed toward the production of a document that is more effective.
[paragraph snipped. It refers to a discussion that took place in member-only space, about a particular concrete suggestion from another member that the working group needs to identify the exrtent to which a tool is responsible for each WCAG checkpoint in the various relative priority checkpoints.]
We are concerned that as people have described the virtues of the existing guidelines draft, those virtues are partially phrased in terms of convenience-for-process: that is, that the guidelines are constructed so as to allow independent revision of the content guidelines (WCAG). We observe that the effort involved in the construction and revision of the guidelines, while very significant for the participants, is a small fraction of the total effort that will be spent by developers understanding and applying them.
We encourage the working group to focus on producing guidelines and/or techniques that will be more immediately intelligible and usable for practicing programmers, even at the expense of potentially creating difficulties within the W3C process.
Particular areas of concern that have been identified are:
We suggest that the working group consider the possibility of a lower conformance level, indicating effectively that the product "does no harm" -- that it may not yet reach A level for supporting accessibility, but neither does it impair or interfere with efforts to provide accessibility. Such a conformance level could do a lot to help eliminate the problem of tools that do interfere with accessible markup.
Finally, we are alarmed by persistent rumors that these guidelines will be used by other groups as the basis for procurement guidelines, ruling out the purchase of products that are not in compliance. We strongly urge the incorporation of language stating unambiguously that any such use is not legitimate.
For the checklist ([WAI-AUTOOLS-CHECKLIST]), also provide links to each item's detailed technique. Right now each links to the Authoring Tool Accessibility Guidelines ([WAI-AUTOOLS]) instead of to the Techniques for Authoring Tool Accessibility ([WAI-AUTOOLS-TECHS]). This would provide an easy link for more detail for those going through the checklist -- the current link doesn't give much more information than is already contained in the checklist.
Future work suggestion: Would there be benefit in creating an open source testing library for authoring tool developers? Like the W3C HTML Validation Service, but libraries that an authoring tool developer could compile into their program that would test a document for WAI compliance. Then W3C could be sure they weren't misinterpreting the specs. This obviously could impact more than just WAI.
Some comments were received from Members who recommended publication "as is". They are given here in no particular order.
The Guidelines provide adequate checkpoints as to what authoring tools should do to produce accessible Web content and to be accessible themselves. Additional detail is needed as to how the guidelines can be implemented, and that detail should be provided in the associated techniques document to be released later.
I was not quite sure I understood the 3 priority levels clearly: A. Priority 1 - If the checkpoint is essential to meeting the goals. B. Priority 2 - If the checkpoint is important to meeting the goals. C. Priority 3 - If the checkpoint is beneficial to meeting the goals.
I had originally thought Priority 1 supersedes both Priorities 2 and 3. And that Priority 2 supercedes Priority 3. In other words, I thought the word "essential" meant both "important" and "beneficial" which would constitute as Priority 1 and whatever is "important", but not "essential" would be Priority 2 and etc...However, after rereading it several times, I realized that isn't the case and instead it uses conformance level as follows:
I am wondering if this is really necessary?
2. Where it states "Ensure that the authoring tool is accessible to author with disabilities" in Guideline 7, I would think it should be Guideline 1 since we should first verify if the software conforms to W3C accessible guidelines, then if so, we can proceed with supporting authoring practices currently specified in Guideline 1.
3. I also read some of the checkpoints outlined in "Techniques for Authoring Tool Accessibility." - working draft of 10/26/99. Under each checkpoints outlined are bullet strategies, I believe we should choose at least one strategy from each checkpoints that would work best for us? I wasn't very cleared about this one.
[Member] is a group that employs a large number of disabled people, some of them with severe handicaps. We welcome this Proposed Recommandation as a new step towards more accessible work environments we could provide them. From a b2c point of view, we wish to greet a specification that will allow us, if tool vendors conform to these guidelines, to establish better contacts with our customers.
Sprinkled throughout the text are internal links to definitions at the end. Many are of the form href=".../WAI_AUTOOLS/#def-something", while many others are like href=".../WAI-AUTOOLS/wai-autools.html#def-something". You should probably use only one form, likely the first.
While [member] does not, to my knowledge, develop authoring tools, it will:
Copyright © 1999 W3C® (MIT, INRIA, Keio ), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.