- From: Ian B. Jacobs <ij@w3.org>
- Date: Sun, 06 Oct 2002 22:44:33 -0400
- To: w3c-wai-gl <w3c-wai-gl@w3.org>
- CC: ij@w3.org
Dear WCAG WG,
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
WG.
Thank you for considering these comments. Don't hesitate to
ask for clarification or additional rationale.
- Ian
[1] http://www.w3.org/TR/2002/WD-WCAG20-20020822/
P.S. This is a resend. I had a mail problem the
first time. My apologies if this appears twice in your
mailboxes.
--------------------
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
remember.
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:
<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.
</example>
Shorter still:
<example>
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]
</example>
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
requirements.
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
case.
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.
------------
Introduction
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
specifications
* Security considerations
----------
Guidelines
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:
http://www.w3.org/WAI/UA/WD-UAAG10-20021003/glossary#def-text-content
Specifically, UAAG 1.0 states:
<blockquote>
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
rendering.
</blockquote>
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"
means.
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
"rendering".
--------------
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
equivalents.
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] http://lists.w3.org/Archives/Public/wai-xtech/2002Sep/0028
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
means.
--------------
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
user.
--------------
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 (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
--
Ian Jacobs (ij@w3.org) http://www.w3.org/People/Jacobs
Tel: +1 718 260-9447
Received on Sunday, 6 October 2002 22:44:42 UTC