W3C home > Mailing lists > Public > public-comments-wcag20@w3.org > August 2003

WCAG 2.0 Draft - Comments.

From: <tina@greytower.net>
Date: Tue, 5 Aug 2003 22:07:18 +0200 (CEST)
Message-Id: <200308052007.h75K7LG22608@localhost.localdomain>
To: public-comments-wcag20@w3.org

  Firstly, I would like to reiterate the comments made by Christian Buehler
  on the use of WCAG 1.0.

  Currently, the 1.0 version of WCAG is the official standard not only in
  Germany, but in the EU. Sweden, where Greytower has its main office, is
  among the countries who has adopted this standard.

  This means that a smooth transition, as Christian points out, between version
  1.0 and 2.0 is absolutely essential. It is not likely that 1.0 will be
  dropped from use in a good, long, time.

  Three points can not be emphasized too strongly:

    1) There must be an exact mapping between versions 1.0 and 2.0, with
       new and deleted material clearly indicated and explained. We will
       all be in it up to our ears if a requirement previously considered
       important is dropped without a logical, clear, explanation.

    2) WCAG 2.0 must have an associated list of checkpoints that can be
       easily, repeatably, and objectively controlled.

    3) WCAG 2.0 must, if at all possible, avoid any and all ambiguities.

  It can never be said too often: the WCAG 1.0 is now firmly entrenched with
  several Governments. This is a good thing. The very last effect we want from
  WCAG 2.0 is muddied waters.

  Further comments on the draft itself:

    1) The document in itself is singularly lacking in clarity. The
       language is reminiscent of bureaucratese  and at times
       nonsensical. After working with accessibility since 1996, I
       find myself shocked by sentences such as 

        "These are additional checkpoints that may be reported in addition
         to Core conformance if the Required Success Criteria for a given
         Extended Checkpoint are satisfied."

       This is difficult to understand, hard to sell, and very nearly
       impossible to follow when reviewing material. I am, personally, still
       not clear on the exact meaning of the above, and would be hard pressed
       to explain it to people who will decide on whether or not to comply
       with this standard.

       The draft must be cleared up, and the language taken to a point
       where it is actually understandable; less this becomes an exercise
       in futility.

    2) The concept of "Core" and "Extended" are horribly unclear. What
       exactly does a "valid conformance" claim mean ? Is the site then
       accessible to *all* ? To some ? To whom ? Will "core conformance"
       mean roughly the same as WCAG 1.0 'A' ? 'AA' ? 'AAA' ?

       This needs to be dealth with right away - preferably by going away
       from the entire concept and staying with the definitions of priority
       1, 2 and 3 from WCAG 1.0 which are clear and easily understandable.

       However, it might be useful to rename them from the rather nonsensical
       'A', 'AA' and 'AAA' to, for instance:

            "Priority 1: Basic"
            "Priority 2: Standard"
            "Priority 3: Complete"

       A question that must be answered is: why were the priorities dropped ?

    3) Issues have been fluffed up and weakened in this draft. We have, for
       instance, this:

        "Perceivable. Ensure that all content can be presented in form(s)
         that can be perceived by any user - except those aspects of the
         content that cannot be expressed in words."

       which is a miracle of grammatical pink-bunny-wabbit phrasing. This
       "guideline" says to me that we should make sure everyone that can
       see, read, and understand can perceive the content. If you don't
       do all three, tough. There is no way this is the intent of the WCAG.

       Even worse is this:

         "... for markup, except where the site has documented that a
          specification was violated for backward compatibility, the
          markup has ... "

       which gives a carte blanche for site developers to ditch any and
       all markup standards as long as they tell users what they are up to.

       Yes, my impressions may be based on being a non-native English
       speaking individual - but quite a few of those who are going to
       apply or attempt to apply WCAG 2.0 will be in the same position.

       If this version of WCAG is to be functional, i.e. be applied and
       followed, then it needs to cut to the chase and state what is

         "Perceivable. Ensure that all content be presented in form(s)
          that can be perceived by any user."

       with an added sidenote of

         "If one form of content is impossible to perceive by a certain
          user, it should be transformed - automatically and without
          information loss - to a form that is perceivable"

  Suggested rewrites and status changes:

    1.1: All non-text content should have a textual alternative explicitly
         associated with it.

         If the content has no informational value, signal this by setting
         an explicitly emply textual alternative. Avoid descriptions if
         possible, if not avoid descriptions that refer to specific physical
         realities (ie. "blue" is often nonsensical to a
         blind person, "high C" might not mean much to deaf visitors)

   1.4a: Text in the content is provided in an ISO character encoding
         scheme such as 8859-1 or 10642, and served according to
         established standards so that a user agent can identify the
         encoding without ambiguity. [The handling of UA defaults should
         go into UUAG]

   1.4b: All abbreviations and acronyms are clearly identified with
         the topic-specific expansion every time they occurr. If the
         expansion is in another natural language than the one used in
         the document itself, this change should be clearly identified.

    1.6: Foreground content is easily differentiable from background for
         both auditory and visual default presentations.

    2.4: Structure and/or alternate navigation mechanisms have been added
         to facilitate orientation and movement in content.

    3.1: Clearly, and according to standard, identify the natural language
         of both the document as a whole and - if any part of the document
         is written in a different language - fragments of it.

(moved to required 1.4b)
    3.2: The definition of abbreviations and acronyms can be unambiguously

    3.4: Layout and behavior of content is consistent or predictable.
         [unless WCAG 2.0 REALLY requires all sites to avoid having identical
          layout from page to page - which it doesn't, when reading the

    4.1: All code, whether structure (such as HTML), presentational (css),
         logical (script), or otherwise should follow a formal, published,
         standard. If possible, the code should pass validity tests for that
         same standard. [a note should be added that this isn't strictly
         possible for scripts, but should ALWAYS be done otherwise]

  Additional comments:

   On the editorial comment on glossaries under 3.2: a standard format
   for linking to glossaries allready exist - atleast for HTML and XHTML - 
   in the form of the LINK element. It would be a good idea to suggest
   this for use on sites utilizing these markup languages.

   On 4.2: what is the point ? Why list a set of "required" technologies
   and not, instead, ensure that the content transforms gracefully to
   the user's physical reality ?

  Finally, it seems to me that alot of GOOD things previously in WCAG 1.0 has
  been removed from 2.0. I've noted that some say that the new version must
  be judged as a stand-alone specification, but as Christian Buehler points
  out: 1.0 will be with us for a long time.

  There are things missing here; things which made sense in WCAG 1.0 and
  would make sense here as well. The priorities need to come back; and the
  language tightened up; the ambiguities taken out.

  As it is, WCAG 2.0 will be terribly difficult to take out in the field;
  doing so is not a prospect I relish.

 -    Tina Holmboe                    Greytower Technologies
   tina@greytower.net                http://www.greytower.net/
   [+46] 0708 557 905
Received on Tuesday, 5 August 2003 16:31:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 17 July 2011 06:13:17 GMT