Comments on WCAG 2.0 (22 Aug 2002 draft)


I have read (most of) the 22 August 2002 draft of WCAG 2.0 [1].
I am happy the group has made such progress. Please forgive the
length of this email; I hope it will be considered constructive.

I make a number of comparisons to UAAG 1.0 in my comments.
Although the documents are different, I think there is a lot of
UAWG experience that can be and should be considered by the WCAG

Thank you for considering these comments. Don't hesitate to
ask for clarification or additional rationale.

  - Ian


P.S. This is a resend. I had a mail problem the
first time. My apologies if this appears twice in your

Part I: Conformance model

I have a number of issues with the current conformance model.

1a) I believe the WCAG WG has structured the conformance model
with a number of goals in mind:

  - Group requirements by theme (guidelines)
  - Prioritize requirements (Levels 1, 2, and 3)
  - Ensure that requirements can be verified

We had the same goals in WCAG 1.0, except that WCAG 2.0
has made progress in verifiability.

UAAG 1.0 and WCAG 2.0 have both adopted an additional mechanism
for grouping requirements: "success criteria" in WCAG 2.0,
"provisions" in UAAG 1.0.

Both "success criteria" and "provisions" are grouped under a
title. In UAAG 1.0, this is a short title. In WCAG 2.0, this
is the "checkpoint text". In both cases, the title itself
is not a requirement.

In UAAG 1.0, all provisions have the same priority, which is
indicated next to the checkpoint title. In WCAG 2.0, all success
criteria are prioritized. WCAG 2.0 does one thing differently: it
allows different "success criteria" under the same checkpoint
title to have different priorities. I think that's a good idea.

In summary: WCAG 2.0 and UAAG 1.0 use very similar mechanisms
but call them by different names. For several reasons (including
consistency with previous WAI Guidelines), I suggest that in
WCAG 2.0:

  a) Checkpoint titles be shortened. Our experience with UAAG
     1.0's short titles is that they are easy to say and

  b) The term "success criteria" be dropped entirely. Instead,
     explain the structure of the document as being:
      - N guidelines.
      - Each guideline has M checkpoints.
      - Each checkpoint may have P provisions.
      - Each provision has a priority.

I recommend calling them "Priority 1/2/3" for consistency
with previous WAI Guidelines. If the definition of "Priority"
need to be changed in WCAG 2.0, change it, but there's no
need to invent a new term for prioritization.

An example:

  Checkpoint 3.1 Provide structure within content.

  Priority 1 provisions:

    1. When appropriate to the content, the following
       must be present:
           a. titles on major sections of long documents
           b. paragraphs

  Priority 2 provisions:

    1. Another provision.
    2. Another provision.

  Priority 3 provisions:

    1. Provide information that allows an
         assistive technology to determine at least one
         logical, linear reading order.
    2. Construct diagrams so that they have structure
       that can be accessed by the user.

Shorter still:

  Checkpoint 3.1 Provide structure within content.

    1. When appropriate to the content, ensure that markup
       is present that identifies the following:
           a. titles on major sections of long documents
           b. paragraphs [P1]

    2. Do this other thing. [P2]
    3. Do yet another thing. [P2]
    4. Provide information that allows an assistive
       technology to determine at least one logical,
       linear reading order. [P3]
    4. Construct diagrams so that they have structure
       that can be accessed by the user. [P3]

Thus, the document boils down to the structure of other
WAI Guidelines except that related provisions can have
different priorities.

Note: This organization is entirely orthogonal to the question of
whether the provisions are verifiable.

Editorial suggestion: Please number provisions (sufficient
criteria) uniquely. I would like to refer to provision 1.1.1 or
1.1.2 and have that be unambiguous. Today, numbering restarts for
each group of priorities.

Editorial suggestion: Please delete sections where there
is no information (i.e., where it reads "(presently no
additional criteria for this level").

Editorial suggestion: Use the active voice rather than
the passive voice in making requirements.

1b) Intermediate conformance levels (1+, 2+). I think a level
that represents an undefined range of what criteria are met will
not help people.  I don't support "2-" either.

1c) Level 1 v. Level A. Is there a reason for changing
conformance level titles from "Double-A" to "2"?

1d) Normative inclusions. I strongly recommend considering the
mechanisms used in UAAG 1.0 to identify normative inclusions and
exclusions. This is already done explicitly in WCAG 2.0's
checkpoint 1.2 ("exception ..."). It is also done implicitly
elsewhere. For instance, in checkpoint 1.2, the bullet "if the Web
content is real-time video with audio, real-time captions are
provided unless the content is a music program that is primarily
non-vocal." The "unless" part is a normative exclusion and should
be identified as such.

Note: I have nothing against using standard English such
as the word "unless". However, there are at least three good
reasons to highlight inclusions and exclusions:

  a) I think that it's easier for the WG to have that model
     in mind when designing the document. Some bullet items
     are not new requirements, they are comments on

  b) I think it helps the reader if there's a predictable
     pattern for finding exclusions and inclusions.

  c) The end result is that there are fewer requirements,
     even if there's the same amount of text. I think
     readers respond favorably to seeing shorter lists.

1e) Sufficient techniques. In UAAG 1.0, we explicitly call out
techniques that are sufficient to satisfy the checkpoint.
WCAG 2.0's checkpoint 2.2 includes a few sufficient techniques.
I would rewrite the checkpoint, for example, as:

<new 2.2>
2.2 Allow control of time limits

  1. Allow users to control any time limits on their reading,
  interaction or responses unless control is not possible due to
  the nature of real-time events or competition.

Sufficient techniques:

  1. Allow the user to turn off any timed interaction
     and carry out that interaction manually. [Priority 1]

  2. Allow the user to adjust the time limit
     over a wide range which is at least 10
     times the average user's preference. [Priority 1]

  3. And so forth.
</new 2.2>

Note: I have other comments on checkpoint 2.2 below; the
present comments are merely about checkpoint structure.

1f) Mixing technical requirements and claim requirements.

WCAG 2.0 combines two types of requirements:

  * Technical requirements.
  * Assertions, or claims.

As an example, checkpoint 1.1 includes a technical requirement:

    "non-text content that can be expressed in words has a
    text-equivalent explicitly associated with it."

but also an "assertion" requirement:

    "the site has a statement asserting that the text-equivalent
    has been reviewed and is believed to fulfill the same function
    as the author intended for the non-text content (i.e. it
    presents all of the intended information and/or achieves the
    same function of the non-text content)."

I am concerned by this confusion of functional requirements and
claim information. WCAG 2.0 requirements should only be
functional requirements. In this case, the functional requirement
buried in the provision is "Text equivalents must fulfill the
same function as the associated non-text content."

A conformance claim is a single assertion that a set of N
(functional) requirements has been satisfied. A "statement
asserting that the text-equivalent has been reviewed and is
believed to fulfill the requirement" is subsumed by such a claim
and therefore is unnecessary. Furthermore, with the current
model, one might have to peruse 50 such mini-claims whereas
a single claim would suffice: This page conforms Level-A.

Phrasing a provision this way does not make the provision more
verifiable. The challenge to the author is to know whether a text
equivalent is really equivalent. Judgment is required in any

I feel quite strongly that the "assertion-like" provisions should
be rewritten as straight functional requirements. The functional
requirements that are too vague to be verified should be refined,
not obscured.

1g) Before the first guideline, explain the structure of
each guideline and each checkpoint, especially what's normative
and what's not. For instance, the status of the bullet after the
second provision of checkpoint 1.1 is unclear.

This is already done throughout the document for definitions,
benefits, and examples. It could be done once up front.

1h) Normative status of definitions. In some cases (such as
"non-text content"), I think the definitions must be normative.
Otherwise, the reader doesn't know what the requirement is.  Some
terms, like "assistive technology" are only informative. In UAAG
1.0, we made the whole glossary normative because it's easier to
have just one glossary. However, some terms (even if normative)
may not have an impact on the spec because they don't appear in
any checkpoints; they may be in informative prose.

Part II: Detailed comments

Status section

1) I think that it is important to include in the status section
a paragraph (or a link to a paragraph elsewhere) that explains
the relation of WCAG 2.0 to WCAG 1.0.  Does WCAG 2.0 supersede
WCAG 1.0? Should authors henceforth ignore WCAG 1.0?

There is such a paragraph just before the section on conformance;
I recommend that it be moved to the status section.


1) The single-word adjectives at the beginning of each guideline
    rub me the wrong way. I find it odd to have an adjective as
    the first word in the title.

2) "Technology-specific" checklists. What is meant by
    "technology-specific"? Does technology mean "format
    specification such as XHTML" or "mobile device"?

3) Structure of the introduction. I recommend considering these
    additional subsections of the Introduction (taken
    from UAAG 1.0):

     * Relation to WAI accessibility guidelines
     * Known limitations of this document
     * Relation to general authoring guidelines and other
     * Security considerations


Note: In an ideal world, each checkpoint requirement would
reflect a user need documented in "How People with Disabilities
use the Web", and would like to that document. Even if that
is not done, it is worth ensuring that all the needs documented
therein are met by the requirements. Below I point out some
requirements that I believe do not belong in WCAG 2.0 but rather
in XAG or UAAG.

Checkpoint 1.1

1) Definition of non-text content. Please consider the UAAG 1.0
definitions of text content, non-text content, etc., which were
written to clarify some definitions in WCAG 1.0 that the UAWG
found inadequate. In particular, it's not clear what makes
something text content or non-text content. I believe the UAAG
1.0 contributes to making this clearer.

Definitions are here:

Specifically, UAAG 1.0 states:

  Both in the Web Content Accessibility Guidelines 1.0 [WCAG10]
  and in this document, text elements are presumed to produce text
  that can be understood when rendered visually, as synthesized
  speech, or as Braille. Such text elements benefit at least these
  three groups of users:

    1. visually-displayed text benefits users who are deaf and
    adept in reading visually-displayed text;

    2. synthesized speech benefits users who are blind and adept
    in use of synthesized speech;

    3. braille benefits users who are blind, and possibly
    deaf-blind, and adept at reading braille.

  A text element may consist of both text and non-text data. For
  instance, a text element may contain markup for style (e.g.,
  font size or color), structure (e.g., heading levels), and other
  semantics. The essential function of the text element should be
  retained even if style information happens to be lost in

The UAWG spent a long time trying to find a workable definition
of non-text content.

Checkpoint 1.2

1) Normative exclusions appear in provisions 2, 4, and after 6.

2) "for all live broadcasts that are professionally produced."
    The term "professional" is subject to much interpretation.
    Does this mean "high quality" or "for money"?

Checkpoint 1.3

1) "any information that is conveyed through presentation
    formatting". I don't know what "presentation formatting"

    Incidentally, I think there are at least four uses of the
    root "present" in the document:

     a) "Presentation" (rendering)
     b) "A presentation" (a multimedia object)
     c) "Present" (available, at hand; cf. checkpoint 3.2)

    I recommend choosing three different terms to avoid confusion.
    The definition after 1.3 uses "presentation" to mean

Checkpoint 1.5

1) The first provision belongs in XAG 1.0, not WCAG 2.0.
    I don't see it in the 3 Oct 2002 XAG 1.0 draft. I suggest
    that the WCAG WG request that XAG include something like:

    "Text formats must be based on Unicode."

2) This leads me to an important point: I think WCAG 2.0 should
    include a requirement that any XML format that the author uses
    must conform to XAG 1.0 (e.g., using a relative priority scheme
    in the manner of ATAG 1.0). I think it will be possible to
    avoid mutual dependencies.

    In past WAI PF meetings, I have promoted a WAI Guidelines
    model where:

     a) Formats must conform to XAG.
     b) Authors must:
          - Use formats that conform to XAG and explain how
            to use the accessibility features that XAG ensures.
          - Do additional things such as use consistent
            navigation, use simple language, and provide text
     c) User agents must:
          - Implement formats that conform to XAG and explain how
            to use the accessibility features that XAG ensures.
          - Do additional things such as ensure keyboard access.
     d) Authoring tools must:
          - Implement formats that conform to XAG.
          - Help authors use these formats to satisfy WCAG requirements.
          - Produce markup that will enable user agents to
            process information with more certainty.

    Thus, I think WCAG, UAAG, and ATAG should be built on top of XAG.

3) "the primary natural language of the content is identified at
    the page level". That is unclear to me; I don't think "page"
    is the right term, though I understand the idea.

Checkpoint 2.2

1) This checkpoint sounds like a user agent requirement, not
    an author requirement. How does the author know that the
    user is allowed to deactivate the time limits? This is
    strictly a UA functionality, even if it's specified in
    a format.

    There's another aspect of this requirement that belongs
    in XAG: The format must ensure that:
         a) Timing can be specified in a manner that the
            user agent can recognize (e.g., in markup, not
            in scripts).
         b) The format spec should also tell user agents to
            conform to UAAG 1.0, checkpoint 2.4.

Checkpoint 3.1

1) This checkpoint title is short and sweet!

2) The first provision assumes that the format includes
    paragraphs; some formats do not include paragraphs.

    I think that XAG needs to ensure that important elements can
    receive titles and descriptions (see my long email about XAG
    1.0 [3]). Then, WCAG 2.0 should say "Use the format's
    available markup for titles, descriptions, captions and audio
    descriptions." In short, the list of desirable objects should
    be part of XAG, and WCAG should just say "use those".


3) The concept of "paragraph" may have some I18N implications; I
    don't know for sure.

4) "Additional ideas..." Each checkpoint in "Techniques for UAAG 1.0"
    includes the following sections:

     * Notes and rationale: Additional rationale and explanation
       of the checkpoint;

     * Who benefits: Which users with disabilities are expected to
       benefit from user agents that satisfy the checkpoint;

     * Example techniques: Some techniques to illustrate how a
       user agent might satisfy the requirements of the
       checkpoint. Screen shots and other information about
       deployed user agents have been included as sample
       techniques. References to products are not endorsements of
       those products by W3C;

     * Doing more: Techniques to achieve more than what is
       required by the checkpoint;

     * Related techniques: Links to other techniques in section
       3. The accessibility topics of section 3 generally apply to
       more than one checkpoint.

     * References: References to other guidelines, specifications,
       or resources.

   WCAG 2.0 includes "who benefits" and "example techniques"
   inline. I understand that one reason may be to avoid requiring
   readers to look at a second document. However, I think that "doing
   more" information should not be in the guidelines as readers
   may think it's part of conformance.

Checkpoint 3.2

1) "content is constructed such that users can control the
     presentation of the structural elements". Not for WCAG 2.0;
     instead there is a XAG component ("ensure control is possible")
     and a UAAG component ("allow control").

2) The Note describes a limitation of this document. This should
    appear in the introduction, in the (new) section "Limits of
    this document."

Checkpoint 3.3

1) "sites that have more than two layers". I don't know what layer

Checkpoint 3.4

1) "key orientation" ... "are generally found in one or two
    locations or their locations are otherwise predictable." This
    checkpoint seems very vague to me. A proposal:

     * XAG should require markup for navigation groups (not
       just single links).

     * Authors should use that markup for navigation groups.

     * Authors specify that, when rendered graphically,
       a navigation group, whenever it is available,
       be rendered in the same place(s) in the viewport.

    There is an inevitable subjective component to this
    requirement: Be consistent except where it's appropriate
    to diverge.

Checkpoint 3.6

1) "If an error is detected..." By whom? This sounds like
    a user agent requirement, not an authoring requirement.

    Error recovery affects everyone, not just users with
    disabilities. I think the UAAG 1.0 requirement is "Ensure that
    messages to the user are accessible." UAAG 1.0 checkpoint 1.3
    requires a text version of every user agent message to the

Checkpoint 4.3

1) "Content is considered complex if the relationships
    between pieces of information are not easy to figure
    out." I don't find this definition helpful.

Checkpoint 5.3

1) The provisions of this checkpoint are not verifiable. Instead,
    these design goals are XAG design goals and should be manifest
    in that specification (though in more concrete terms).

    Perhaps this is the checkpoint that should read "Use formats
    that conform to XAG."

Checkpoint 5.4

1) This checkpoint requires conformance to UAAG 1.0 Level A,
    but that is an incomplete profile. Please refer to sections
    3.1 and 3.3 of UAAG 1.0 for information about how to
    include a UAAG 1.0 conformance profile in a specification.

    [This is likely to require further discussion.]

Ian Jacobs (
Tel:                     +1 718 260-9447

Ian Jacobs (
Tel:                     +1 718 260-9447

Received on Sunday, 6 October 2002 22:44:42 UTC