Comments on 26 July 2000 WCAG 2.0 Draft


I very much like the idea of creating a more abstract WCAG 2.0.
Please consider my comments below. Part 1 requests a change.
Part 2 requests an addition (in WCAG 2.0 or in a central document).
Part 3 plays with the principles themselves.

Part 1) I don't think it's a good idea to redefine the terms 
   Guidelines and Checkpoints. I think doing so will create confusion
   and I don't understand why it's necessary.
   a) The checkpoint is the fundamental unit of action and conformance.
   b) Everything else is either organization (Guidelines) or
      detail (Technique). 
   c) Principles are nice, and they can help convey a model, but I don't
      think that they are any more than further organization. 
   d) Please don't shift terms! (A means what B used to mean and B means
      what C used to mean). If you want more granularity, please just
      create checkpoints consisting of more than one statement: "You
      do A and B and C but aren't required to do D."
   e) I believe that we have in the past (in both WCAG and ATAG)
      two levels of conformance: "you must do this to meet the
checkpoint and
      by meeting all the checkpoints, you satisfy the Guideline." We
      this because it confused readers. And I don't think it's
      If a Guideline is purely organizational, then you don't have to 
      satisfy it. You only have to satisfy the checkpoints (which are

Part 2) I think it's important to convey the following (either in WCAG
2.0 or
   in a document central to all the guidelines):

   a) The WAI accessibility model assigns responsibilities to different
      parties for ensuring accessibility: authors, user agent
      and users.

      For instance, it is the responsibility of the author to provide
      alternative content, the responsibility of user agent developers
to ensure
      that it is synchronized and to allow control over style, and it is
      responsibility of the user to procure assistive technology. One
      also consider two other entities in assigning responsibilities:
      authoring tool developers and specification writers. Thus, it is
      responsibility of the spec writer to ensure that a specification
      accessibility features, separates structure from style, etc.

   b) The requirements of the WAI Guidelines are determined by the
      Group based on (in no particular order):  
      1) User needs
      2) Technology readily available to users and authors, including
         authoring software, assistive technologies, operating systems,
         and specifications. Cost and feasibility do factor into 
         the requirements, though more weight is given to user
         in general. Making some assumptions more explicit will make the
         document easier to write and easier to communicate to readers.

         For example, consider why text is so important:

          + Today, speech synthesis technology is readily available and
            fairly reliable.

          + Most mainstream user agents do not include speech synthesis

          + Optical character recognition and audio-to-speech
            transcription technology is either not reliable enough or
            resource intensive or too expensive.

          + Text is easy for authors to create

       Therefore, since today it is easy for authors to create text 
       documents that today's readily available technologies can
       render to eyes, ears, and fingertips, it is a requirement to
       provide text equivalents to non-text content. (Refer to comments
       from Eric Hansen on this topic [2]).

Part 3) Organizing principles. While I'm at it, here's how I might
       break down the requirements (without indicating here which 
       responsibilities are for authors, user agent developers, and

       WARNING: The following organization and commentary has been
       jotted down capriciously and is subject to emphatic retraction
       by the author. Comments are welcome!

   a) Requirements related to perception and the senses: content
      and user interface must be usable through sight, hearing, and
      touch. [Again, note that this makes technological assumptions. 
      Perhaps interaction through brainwaves directly will some day
      be possible. But it's not today.] This principle includes
      all requirements related to the senses: colors, renderings, 
      control of style due to sensory needs, etc. I think it would also
      include requirements related to space (e.g., don't require the
      user to move through space to activate a functionality, the
      that content be available in serial form) and time
      (e.g., maintain synchronization on the one hand, and allow the
      user to control time scales on the other). It also involves
      communication through APIs between user agents since the assitive
      technologies are generally there to compensate for sensory

   b) Requirements related to meaning: ensure that the user can
      the author's intended meaning. This principle inclues all 
      requirements related to markup (separation of style and
      to validity of markup, consistency, writing style, simplicity, 
      use of graphics, overviews, summaries, use of metadata, etc.

   c) Requirements related to usability: This principle includes
      for navigation, control of sudden changes to content,
      configuration, control, repair strategies, implementation of
      following system conventions, consistency in the user interface, 
      user control of changes to the user interface, etc.

   Of course, some requirements don't fall perfectly under a particular
   principle, others may fall into more than one. Some reasons for this
   choice of groupings:

   1) I suspect that sensory requirements can be generalized to 
      device requirements. I can't prove this. <grin>

   2) I think it's useful to separate meaning and sense, just as it's
      useful to separate structure and style. Structure is close to
      meaning and style is all about rendering (to the senses). It's
      useful when designing content (I think) to consider meaning
      before rendering issues, even if the two worlds collide almost
      immediately (and in the authoring process they are frequently
      performed close together if not at the same time.
      For instance, it's useful to provide graphics because
      they can convey meaning more effectively than text in many cases.
      But because they're graphics, they raise some other accessibility
      issues and text equivalents are necessary.

   3) Reviewers of the UA Guidelines requested that "content"
      and "UI" requirements be clearly identified as such. I think that
      identifying requirements related to using the content, and not
      just reading it, may be useful. Obviously, navigation bars are
      of content, but some of them differ little from UA "back buttons".
      The usability of a page, site, or piece of software feels
      to me than understanding the author's meaning. 

 - Ian

Ian Jacobs (
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

Received on Monday, 14 August 2000 15:56:08 UTC