Re: ERT comments

>
> >This document trys to make clear  that the WWW should
> >enable everyone, especially those with disabilities.
> >
>CR::Do we really need to explain this? The WWW enables people to pursue 
>lofty goals, achieve personal enlightenment, fulfill their destiny -or- 
>just wallow in porn.
>
> >avoid the 'cry wolf' syndrome.
> >
>CR::Could we rephrase this as "avoid tiring the user."?

I think we can just cut the reference to "cry wolf".  I also have addressed 
Len's first comment in this proposal (here is a rewritten introduction in 
its entirety). Note, that i did not change the last paragraph. it is very 
eloquent.
<blockquote>
The Web Accessibility Initiative (WAI) has produced a foundation document, 
The WAI Web Content Accessibility Guidelines (WCAG 1.0), that describes 
what must be done to make a Web page accessible to all.  Tools are needed 
to help authors determine if a web site is accessible to everyone and to 
help repair it if it is not.

This document builds on the WCAG 1.0 foundation by outlining techniques 
that evaluation and repair tools may use to uncover accessibility problems 
and possibly repair them. These techniques may be used by those who create 
web authoring tools or by anyone interested in creating accessible Web 
documents.

It is important that people with disabilities are included in the "anyone 
interested in creating accessible Web content." Creating accessible Web 
content is as important as accessing Web content. Therefore, evaluation and 
repair tools themselves need to be accessible to people with 
disabilities.  However, this document does not describe how to make the 
user interface accessible. Please refer to the Authoring Tool Accessibility 
Guidelines 1.0 for information on making the user interface accessible.

Many people using evaluation and repair tools may be new to the Web and 
will not be familiar with the various markup languages that are used. Many 
others will not know about Web accessibility.  Tools should be intuitive 
and easy to use and available at a minimal cost. Tools should not generate 
excessive warnings or false positive accessibility errors.

It is clear that only a limited set of the WAI Guideline's checkpoints may 
be objectively tested by a software tool. There will still be a dependence 
on the user's ability to use common sense to determine conformance to the 
guidelines. It is imperative that any tool have features that assist in 
reminding, without nagging; in helping, without demeaning; in suggesting, 
without demanding. We hope that the techniques in this document, 
implemented in software programs, will gently guide authors along the path 
to more accessible documents.
</blockquote>

>
> > Messages displayed to the author if a problem is found
> > LRK:: Change to "Example of a message displayed.
> >
>CR:: Should the 'Example Language' section remain in the document? If so, 
>then I agree with your suggestion.
>
> >
> > Technique 1.1.D [priority 1] Check applets for ALT text
> > LRK:: Is this needed if the user, in accordance with 1.1.E,
> > has code before </applet> that shows up when
> > user agent skips applets?
> >
>CR:: I think it is needed. The applet ALT text should be short while the 
>text within the APPLET tags should give a longer description of the 
>applet. Wendy - is this right?
>

yes.

--w
--
wendy a chisholm
world wide web consortium
web accessibility initiative
madison, wi usa
tel: +1 608 663 6346
/--

Received on Friday, 4 February 2000 17:03:34 UTC