W3C home > Mailing lists > Public > w3c-wai-au@w3.org > April to June 1999

Re: Merging or Splitting Sections

From: Charles McCathieNevile <charles@w3.org>
Date: Tue, 11 May 1999 17:07:14 -0400 (EDT)
To: Kynn Bartlett <kynn@idyllmtn.com>
cc: w3c-wai-au@w3.org
Message-ID: <Pine.LNX.4.10.9905111702450.6913-100000@tux.w3.org>
This chopping and rechopping sections went on for most of the pre-rec life of
the Web Content Guidelines. I can think of 2 new ways of dividing the
document up in the last 10 minutes. I think that the various divisions are
arbitrary, although some will be readily understood by more people than
others.

The two groups whose input is important is producers of tools and users of
tools (who are trying to decide whether their tool does what we think it
ought to do). If there is a division which clearly makes more sense to these
groups than having a single set of guidelines, then there would be an
argument for using that division. But I am not convinced that there is such a
division.

Charles

On Tue, 11 May 1999, Kynn Bartlett wrote:

  I had originally identified the sections as follows:
  >2.1 Generate standard markup
  >2.2 Support all accessible authoring practices of W3C Recommendations
  >2.3 Ensure that no accessibility content is missing
  >2.5 Preserve existing accessible structure or content
  >
  >These all deal with the markup functions of the tool.  (Incidentally,
  >how different are 2.3 and 2.5?)
  >
  >2.4 Integrate accessibility solutions into the overall "look and feel"
  >
  >This is a user-interface guideline.
  >
  >2.6 Provide methods of checking and correcting inaccessible content
  >
  >This is a "correcting/validation/repair" guideline.
  >
  >2.7 Promote accessibility in help and documentation
  >
  >This is a documentation and education guideline.
  >
  >3.1 Follow principles of accessible design
  >3.2 Ensure independence of authoring and publishing environments.
  >3.3 Provide accessible navigation
  >3.4 Ensure accessible representation of elements
  >
  >These are user interface guidelines.
  
  Maybe we need to have four or five "larger" guidelines with checkpoints
  and techniques under each:
  
  A.  Create Accessible Documents
  
  >2.1 Generate standard markup
  >2.2 Support all accessible authoring practices of W3C Recommendations
  
  B.  Correct Inaccessibility Problems
  
  >2.3 Ensure that no accessibility content is missing
  >2.5 Preserve existing accessible structure or content
  >2.6 Provide methods of checking and correcting inaccessible content
  
  C.  Document Accessible Authoring Practices
  
  >2.7 Promote accessibility in help and documentation
  
  D.  Provide An Accessible User Interface
  
  >3.1 Follow principles of accessible design
  >3.2 Ensure independence of authoring and publishing environments.
  >3.3 Provide accessible navigation
  >3.4 Ensure accessible representation of elements
  
  E.  Integrate Accessibility Naturally
  
  >2.4 Integrate accessibility solutions into the overall "look and feel"
  
  --
  Kynn Bartlett <kynn@hwg.org>
  President, Governing Board Member
  HTML Writers Guild <URL:http://www.hwg.org>
  Director, Accessible Web Authoring Resources and Education Center
    <URL:http://aware.hwg.org/>
  

--Charles McCathieNevile            mailto:charles@w3.org
phone: +1 617 258 0992   http://www.w3.org/People/Charles
W3C Web Accessibility Initiative    http://www.w3.org/WAI
MIT/LCS  -  545 Technology sq., Cambridge MA, 02139,  USA
Received on Tuesday, 11 May 1999 17:07:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:39:42 UTC