Comments on 26 July 2000 WCAG 2.0 Draft

Hello,

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
implementation
      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
must
      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)
considered
      two levels of conformance: "you must do this to meet the
checkpoint and
      by meeting all the checkpoints, you satisfy the Guideline." We
dropped
      this because it confused readers. And I don't think it's
necessary.
      If a Guideline is purely organizational, then you don't have to 
      satisfy it. You only have to satisfy the checkpoints (which are
      prioritized).

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
developers, 
      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
the
      responsibility of the user to procure assistive technology. One
may
      also consider two other entities in assigning responsibilities:
      authoring tool developers and specification writers. Thus, it is
the
      responsibility of the spec writer to ensure that a specification
includes
      accessibility features, separates structure from style, etc.

   b) The requirements of the WAI Guidelines are determined by the
Working
      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
requirements
         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
            technology

          + Optical character recognition and audio-to-speech
            transcription technology is either not reliable enough or
too
            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
       users.

       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
requirement
      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
limitations.

   b) Requirements related to meaning: ensure that the user can
understand
      the author's intended meaning. This principle inclues all 
      requirements related to markup (separation of style and
structure),
      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
requirements
      for navigation, control of sudden changes to content,
documentation,
      configuration, control, repair strategies, implementation of
standards,
      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"
requirements
      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
part
      of content, but some of them differ little from UA "back buttons".
      The usability of a page, site, or piece of software feels
different
      to me than understanding the author's meaning. 

 
 - Ian

[1] http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-20000726.html
[2] http://lists.w3.org/Archives/Public/w3c-wai-ua/2000JulSep/0184.html
-- 
Ian Jacobs (jacobs@w3.org)   http://www.w3.org/People/Jacobs
Tel:                         +1 831 457-2842
Cell:                        +1 917 450-8783

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