- From: Jutta Treviranus <jutta.treviranus@utoronto.ca>
- Date: Tue, 31 Aug 1999 16:47:50 -0400
- To: w3c-wai-au@w3.org
- Cc: jbrewer@w3.org
I propose the following rewording to the last two paragraphs of the Introduction (in response to Judy's comments). Somehow in the multiple re-edits we have blurred the distinction between making the tool accessible and making a tool that generates accessible content (note the sentence : "It does design issues directly related to accessible authoring tools, such as automation, accessibility checking, appropriate documentation, navigation mechanisms, prompts, the adoption of system conventions, and other features that will result in authoring tools which allow users to create accessible content regardless of disability.") Present wording is: An accessible authoring tool is accessible software that produces accessible content for the Web. For detailed information about the production of accessible content this document relies on the Web Content Accessibility Guidelines [WAI-WEBCONTENT]. Similarly, this document does not directly address the general design of accessible software. It does design issues directly related to accessible authoring tools, such as automation, accessibility checking, appropriate documentation, navigation mechanisms, prompts, the adoption of system conventions, and other features that will result in authoring tools which allow users to create accessible content regardless of disability. Because most of the Web is created using authoring tools, they play a critical role in ensuring the accessibility of the web. A separate document, entitled Techniques for Authoring Tool Accessibility [WAI-AUTOOLS-TECH], provides suggestions and examples of how each checkpoint might be satisfied, It also includes references to other accessibility resources (such as platform-specific software accessibility guidelines) which give additional information on how a tool may satisfy each checkpoint. Readers are strongly encouraged to become familiar with the techniques document. Please note that while there may be many helpful suggestions there the requirements which need to be fulfilled are the checkpoints in this document, and ways other than those suggested may be appropriate for some tools. Proposed revision is: An accessible authoring tool is accessible software that produces accessible content for the Web. Thus the goals of this document can be stated as follows: that the authoring tool be accessible to authors regardless of disability, that the authoring tool generate accessible content by default, and that the authoring tool support and encourage the author in creating accessible content. Because most of the Web is created using authoring tools, they play a critical role in ensuring the accessibility of the Web. Since the Web is both a means of receiving information and communicating information, it is important that both the web content produced and the authoring tool itself be accessible. For detailed information about what constitutes accessible content this document relies on the Web Content Accessibility Guidelines [WAI-WEBCONTENT]. The document provides guidelines for designing authoring tools that generate web content that conforms to the Web Content Accessibility Guidelines and that support and encourage authors to create content that conforms to the Web Content Accessibility Guidelines. Similarly,this document does not address general accessible software design but relies on other sources. It does address accessible design considerations specific to Web authoring tools. A separate document, entitled Techniques for Authoring Tool Accessibility [WAI-AUTOOLS-TECH], provides suggestions and examples of how each checkpoint might be satisfied. It also includes references to other accessibility resources (such as platform-specific software accessibility guidelines) that give additional information on how a tool may satisfy each checkpoint. Readers are strongly encouraged to become familiar with the techniques document. Please note that the techniques are merely suggested implementations of the checkpoints, alternative strategies may be used to meet the requirements of the checkpoints. End of revision As previously suggested I have included the goal statement and have addressed the awkward wording of the second paragraph. Jutta
Received on Tuesday, 31 August 1999 16:45:25 UTC