Introduction

I propose using the following text (carefully copied from Ian *grin*) as the
introduction to the guidelines, to replace the current introduction and scope
section:

The guidelines in this document are designed to help authoring tool
developers understand, and thereby reduce, accessibility barriers to the
creation of Web content.  In these guidelines, the term authoring tool refers
to the wide range of software used for creating Web content, including:
  
 +  Editing tools specifically designed to produce Web content (e.g., WYSIWYG
    HTML editors, SMIL authoring packages);

 +  Tools that offer the option of saving material in a Web format (e.g.,
    word processors or desktop publishing packages);

 +  Tools that translate documents into Web formats (e.g., filters to
    translate desktop publishing formats to HTML);

 +  Tools that produce multimedia, especially where it is intended for use
    on the Web (e.g., video production and editing suites);
 +  Tools for site management or site publication, including on-the-fly
    conversion and Web site publishing tools;
 +  Tools for management of layout (e.g., CSS formatting tools).
  
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. This document does, however, discuss design issues
directly related to accessible authoring tools. One such issue is automation.
Authoring tools should automate the mechanical aspects of content development
for two reasons:

1. In many cases, it is easier for the tool to ensure that generated content
   meets the requirements of the Web Content Accessibility Guidelines.
2. Automation allows users to reduce repetitive work and to concentrate
   instead on accessible authoring practices that require human creativity
   (such as authoring alternative text).
  
In addition to automation, the guidelines discuss how appropriate
documentation, navigation mechanisms, prompts, the adoption of system
conventions, and other features will result in authoring tools that allow
users to create content regardless of disability.

Accompanying this document is an informative reference, Techniques for
Authoring Tool Accessibility [AU-TECHNIQUES], which provides suggestions and
examples of how each checkpoint might be fulfilled, as well as further
reference where appropriate, such as to general software accessibility
guidelines, or documents which address particular issues related to a
checkpoint. Readers are strongly encouraged to become familiar with the
techniques document, and reminded 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 suggesteed may be
appropriate for some tools.
  

In the techniques document I would leave out the first and last paragraph.
For the first paragraph I suggest:

This document is intended as an informative adjunct to the Authoring Tool
Accessibility Guidelines [WAI-AUTOOLS]. Although it reproduces the guidelines
and checkpoints from that document it is not a normative reference.  It
contains suggesteed implementation techniques, examples, and references to
othger sources of information, as an aid to developers seeking to implement
the Authoring Tool Accessibility Guidelines, and it is expected to be updated
in response to queries raised by implementors of the Guidelines. The
techniques introduced here are not necessarily the only way of fulfilling the
checkpoint, nor are they necessarily a definitive set of requirements for
fulfilling a checkpoint.


And in place of the last paragraph I suggest


To understand the accessibility issues relevant to
authoring tool design, consider that many users may be creating
documents in contexts very different from your own:

 +  They may not be able to see, hear, move, or may not be able to process
  some types of information easily or at all.
 +  They may have difficulty reading or comprehending text.
 +  They may not have or be able to use a keyboard or mouse.
 +  They may have a text-only display, or a small screen.

In addition, accessible design will benefit many people who do not have a
physical disability (yet) but who are in a variety of situtations which give
them similar needs. For example they may be working in a noisy environment
and unable to hear, or need to use their eyes for another task, and be unable
to view a screen. They may be using a small mobile device, with a small
screen, no keyboard and no mouse.


Charles McCN


--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://www.w3.org/People/Charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA

Received on Monday, 9 August 1999 21:08:06 UTC