Re: comments on 31 March draft

My comments marked CMN: William's original stuff WL:

On Mon, 5 Apr 1999, William Loughborough wrote:

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

CMN:
I agree that we don't need to say manufacturers and developers. I'm not
sure that we get much by adding vendors - I would suggest dropping
manufacturers and leaving it at that.

WL:  
  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".
  
CMN:
I think we should add a paragraph which states the importance of authoring
tools themselves being accessible. (A side benefit of having disabled
people write pages is that they often understand accessible design better
than 'non-disabled' people, having experienced the difficulties frequently
and worked out solutions.

I suggest we shorten the second paragraph, by removing the parentheses,
and removing everything that follows them in the sen=cond sentence. The
following is my proposed abstract:

Abstract:

This document provides guidelines for Web authoring tool manufacturers and
developers. The purpose of this document is two-fold: to assist developers in
designing authoring tools that generate accessible Web content and to assist
developers in creating an accessible authoring tool user interface.
 
Accessible Web content is achieved by encouraging authoring tool users
("authors") to create accessible Web content through mechanisms such as
prompts, alerts, checking and repair functions, help files and automated tools.
This will result in the proliferation of Web pages that can be read by a 
broader range of readers and in authoring tools which can be used by a broader 
range of users.

It is equally important that all people can be the authors of Web content,
rather than merely recipients. It is therefore of critical importance that the
tools used to create this content are themselves accessible.
 
This document is part of a series of accessibility documents published by the
W3C Web Accessibility Initiative.

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

CMN:
I would suggest "enabling, assisting, informing and correcting..."
  
WL:
  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.

CMN:
I like just "... its importance."

WL:  
  Section 2 is pretty well cooked...

CMN:
Well, there is still room for improvement (especially in the area of
techniques) but it is certainly getting there (grin).

WL:
  ... 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.
  
CMN:
This is one reason why I support the idea of having a single section. The
other is that I think there are genuine areas of overlap - rather than try
extra hard to ensure that we are not misinterpreted as saying something
that is another section, I think it makes more sense to have the
guidelines which seem to cross over (in particular 2.6 and 2.7) as those
in between the guidelines which fairly clearly relate to one section or
the other. However this is an open issue, and does not need urgent
resolution anyway.

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

CMN:
I agree. I don't think they are distinct, just that they are more general
approaches, and it is valuable to separate them out from among the
individual checkpoints. (We need to update the example implementation of
ALT - it has fallen behind as the guidelines and checkpoints have changed.
It will happen in due course.

Charles McCathieNevile

Received on Thursday, 8 April 1999 19:14:31 UTC