Re: Introduction

So taking into account Ian's proposals, I now have the following suggested
texts:

For the guidelines:

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.

A seperate document, entitled Techniques for Authoring Tool Accessibility
[AU-TECHNIQUES], 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 suggesteed may be appropriate for some
tools.

And my proposed techniques introduction:

This document complements 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 suggested
implementation techniques, examples, and references to other sources of
information as an aid to developers seeking to implement the Authoring Tool
Accessibility Guidelines. It is expected to be updated in response to queries
raised by implementors of the Guidelines, for example to cover new
technologies. 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.

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 but with 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.

Received on Tuesday, 10 August 1999 16:07:56 UTC