Re: Introduction

Charles McCathieNevile wrote:
> 
> 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:

Some good stuff snipped <grin>
 
> An accessible authoring tool is accessible software that produces accessible
> content for the Web. 

Here's an issue: does it have to be for the Web? Does an intranet count?
in the UAGL, we are facing a similar puzzle: we say that documentation
must conform to the WCAG. Does this mean electronic documentation
only? Documentation for  the Web only? This is an open issue for the
UAGL WG.

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

I don't like the previous transitional sentence, but I don't have
a substitute for now.

> Accompanying this document is an informative reference, 

The word "Accompanying" will confuse people. In WCAG we say
"In a separate document..."

> 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

references

> guidelines, or documents which address particular issues related to a
> checkpoint.

I propose simplifying the above sentence to:

"A separate document, entitled "...." [AU-TECHNIQUES], provides
suggestions and examples of how each checkpoint might be satisfied.
It also includes references to other accessibility resources 
(including software accessibility guidelines) that shed additional
light on how a tool may satisfy each checkpoint.

> Readers are strongly encouraged to become familiar with the
> techniques document, and reminded that while there may be many helpful

Propose replacing "," by full stop. Then start next sentence
with "Please note that while..."

> 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

Change "is intendetd as an informative adjunct to" to "complements"

> Accessibility Guidelines [WAI-AUTOOLS]. Although it reproduces the guidelines
> and checkpoints from that document it is not a normative reference.  It

Change "It" to "The current document"

> contains suggesteed implementation techniques, examples, and references to

s/suggesteed/suggested

> othger sources of information, as an aid to developers seeking to implement

s/othger/other
Also drop comma after "information'

> the Authoring Tool Accessibility Guidelines, and it is expected to be updated

Change comma to full stop. 

> in response to queries raised by implementors of the Guidelines. The

Any interest in mentioning changes in technology? That may be part of 
queries.

> 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

I don't like the term "yet". It sounds ominous, almost threatening.
I understand that this may refer to people aging, but it's not necessary
editorially. 

> them similar needs. 

Propose changing "but who are in a variety of situations which give
them similar needs" to "but with analogous functional requirements."

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

 - ian

-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel/Fax:                     +1 212 684-1814

Received on Tuesday, 10 August 1999 13:03:42 UTC