comments on 31 March draft

A little wordsmithing.  

In the Abstract we start with "This document provides guidelines for Web
authoring tool manufacturers and developers. The purpose of this
document is two-fold:..."  I propose "...tool developers and vendors;
its purpose is two-fold:...".  I think the "developers" are in fact the
"manufacturers".

The second paragraph needs a lot of work because it doesn't say enough
about the fact that one of the main purposes of our effort is to see to
it that the "authors" aren't just encouraged to produce accessible Web
content but also emboldened to undertake careers as authors, which is at
this time an almost proscribed endeavor, unless they're "supercrips".

One of the joys of being devoted to WAI is that I am able to suffer
inclusion in what is mostly a mission of forbearance on the part of the
folks who know about all these __MLs and arcane scripting dialects as I
haven't spoken much "techno" since my days of using assembler as a 
second language.  So I will continue to lobby for the paramount
importance of what we've been calling "Section 3".

In the Introduction we find "For the purposes of this document the term
"authoring tool" will refer to authoring tools, generation tools and
conversion tools. These guidelines emphasize the role of the user
interface in informing, supporting, correcting and motivating authors
during the editing process."

Again the second sentence might mention "enabling" or even "empowering"
because the tradition of an attitude that says "let's help those less
fortunate.." is altogether too strong and pervasive.  I think the
redefinition of what constitutes an "authoring tool" is underway in most
of our minds because authoring, generating, and converting are somehow
all just "output creating" mechanisms and to try to guess what forms
this will take next year is vain.

In 1.1 is "What must/should/may I do to make an authoring tool (and the
content it produces) accessible?" which I find really good.  For one
thing, if we make the tool accessible then the parenthetical notion
raised is likelier.

In 1.2 "Each checkpoint in this document is assigned a priority that
indicates its importance for users." --- and authors; or perhaps just
"... its importance."  The language in [Priority...] also matches the
attitude that priority (as distinct from Priority) is given to the
accessibility of the tool as well as its output.

Section 2 is pretty well cooked and the discussions about Section 3 seem
to be centered around whether to include its guidelines within 2.  We
must not lose the notions expressed in the Section 3 introductory text
but if those dicta are sufficiently clear from such things as discussed
above it may be smoother to in effect say "of course this is all of a
piece since the notion of the tool being accessible is clearly #1 and
the unswerving insistence on this can only serve to make the
accessibility of the output a natural consequence of that stance." 
I.e., the same language now prefacing Section 3 can be incorporated in
the explanatory portion of the guidelines, no matter what their "number"
since they will have an appropriate priority and the tendency to think
of them as some separate (but equal) little ghetto may actually be more
readily countenanced if they're not in the main body of the document -
which is Section 2.

I have more trouble with the concept that "Samples" are somehow distinct
from "techniques" since I feel that either can be either.

That's enough for tonight.

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

Received on Monday, 5 April 1999 21:19:33 UTC