draft

In the second paragraph of the Abstract I think to emphasize Kynn's
point that such items as tutorials are a part of the documentation that
"help files" should be parenthetically (or elsewise) expanded to include
*any* aspect of documentation - and for some reason I would prefer
"only" to "merely". And not to put too fine a point on it but "would
result" instead of "will result" would be more realistic.

In the intro the second and third bullets after "including:" might be
made into one since saving as HTML is an inherent part of translating
documents. "It does design issues..." seems like a typo for "It does
address issues..."?

I really want to strongly second Gregory's motion raised in regard to
whether certain things (in this case ABBR and ACRONYM stuff) is
"essential to accessibility". The point that we are dealing with
"stifling inaccessibility" is more cogent. Just as the proper use of
structural markup to assist in more "level playing field" conditions,
many things that we are deciding are "not essential" depend on whose ox
is being gored. While we can't directly do much about blind guys'
inability to make "overview scans", whenever we can, we should - it's
why we go through this exercise. The resistance with which a suggestion
to work without mouse/monitor for a day is met is adequate proof of all
this - once you've done this, you never want to do it again. We (that's
the blindless "we") *think* we know what it's like to eschew monitors
but the reality is a bit more daunting when it's actual experience
instead of a "mental experiment".

The upshot of this is that "beneficial" and "essential" as used in the
priority definitions should be very carefully evaluated in every case.

I think the "Note" explaining "spelling out" is gratuitous.

Finally, I suggest dele-ing "by that date".

I'll get to the Guidelines themselves next time.

-- 
Love.
            ACCESSIBILITY IS RIGHT - NOT PRIVILEGE
http://dicomp.pair.com

Received on Wednesday, 18 August 1999 12:31:41 UTC