Structure of deliverables: guidelines and techniques documents

The following message attempts to summarize the open issues which have
arisen with respect to the structure and composition of the working
group's deliverables, in particular the role and status of techniques
and associated requirements.

Thanks are due to Gregg for his prompt and helpful review of this summary.


Outline:

The structure of this working group's deliverables is as follows:

(a). Guidelines/checkpoints/success criteria, as published in the
principal guidelines document. These are formulated in
"technology-neutral", yet precise terms.

(b). Concise, concrete explanations of how to meet each checkpoint. Some
of these are, but others may not be, technology-specific (see the
discussion below).

(c). Miscellaneous commentary, code examples explanatory materials,
 and alternate ways to accomplish the strategies which again may be
specific to particular technologies.

HOW THESE RELATE TO 1.0
In WCAG 1.0, layer (a) appears as a W3C Recommendation (Web Content
Accessibility Guidelines 1.0), though it should be noted that the
guidelines and checkpoints are not expressed in fully general terms
and involve subtle technological assumptions and dependencies which
have been largely eliminated in the WCAG 2.0 working drafts.

Layers (b) and (c) are combined, at least conceptually, in techniques
documents, though the means of satisfying checkpoints have not been
expressed as concise and clearly identifiable assertions. In WCAG 1.0,
there are no success criteria associated with each checkpoint.



Open issues:

1. What should appear in layer (b), and how should the requirements at
   this level be organised? Obviously, some of the "implementation
   strategies" are technology-specific (that is, they pertain to
   particular standards and formats, such as (X)HTML, SVG, etc.).
   However, there are checkpoints under guideline 3, and possibly
   guideline 2 as well, which would be implemented in largely the same
   manner irrespective of which technology is to be used. For example,
   in applying checkpoint 3.3, the technology (HTML< PDF< SVG etc.)
   is irrelevant to the way in which an author proceeds to satisfy the
   checkpoint. In other cases, there are only trivial differences (for
   instance, checkpoint 3.4 obviously involves the association of
   sounds/images with content, but the markup code or other mechanism
   with which to accomplish this is well known and there would be
   little benefit in writing separate techniques for each technology
   in relation to such a checkpoint). Rather, techniques related to
   checkpoint 3.4 would need to explain under what circumstances
   auditory/graphical supplements aid comprehension and how to design
   them effectively.

Similar issues arise in respect of checkpoint 1.1: although the
mechanisms by which text equivalents are provided varies according to
the technology which is used, the underlying conception of what
constitutes an adequate "text equivalent" remains constant.

In WCAG 1.0, these issues were addressed by writing a "core
techniques" document which discussed issues and strategies of broad
application that were not technology-specific, and a set of
technology-specific documents (HTML, CSS, etc.).

A comparable solution is needed for WCAG 2.0.

2. How should the requirements of layer (b) be formulated?

A central concern underlying discussions of WCAG 2.0 has been that the
"implementation strategies" be expressed in clearer and more concise
terms. For example, it has been argued that where there are
alternative means of satisfying a checkpoint using a specific
technology, it should be made plain to the reader exactly how many
alternatives are provided, what they are, and whether each of them is
sufficient (by itself or in specified combinations) to satisfy the
success criteria stipulated in the guidelines, and hence the
checkpoint itself.

The working group needs to decide whether the strategies set forth in
layer (b) should follow a prescribed format, and if so, what that
format should be.

3. Should layer (b) be included in one or more normative documents
   (i.e., W3C Recommendations), or should it be informative only?

Advantages of normativity:

I. Developers who successfully implement relevant requirements from
   layer (b) will thereby have some assurance that they have satisfied
   the corresponding checkpoint or checkpoints.

II. Layer (b), as part of a W3C Recommendation, would receive the same
   close scrutiny and careful review as the guidelines themselves.

Disadvantages of normativity:

I. Normative documents are slow to change as technology evolves, due
   to the requirements of the W3C process.

II. If layer (b) were normative, this would complicate the over-all
   conformance scheme of the guidelines, because it would be necessary
   to deal with the possibility that an implementor could successfully
   satisfy the success criteria associated with a checkpoint, but in
   ways other than those prescribed in layer (b).

III. The existence of success criteria in WCAG 2.0 provides greater
   clarity regarding what must be achieved in order to satisfy each
   checkpoint. This at least partially satisfies the need for
   precision and certainty which motivates the desire, on the part of
   some members of the group, that layer (b) be normative. Hence, it
   may no longer be considered necessary to make layer (b) normative.

IV. If the requirements in layer (b) do not provide complete
   "implementation strategies" for satisfying each checkpoint, then it
   would still be necessary for implementors to assess their content
   by reference to the guidelines document itself, rather than solely
   in relation to various "specific" (layer b) requirements. Thus
   there may be little advantage to developers if layer (b) were
   normative.

4. What should layers (b) and (c) be called? The question which has
   received most consideration in this context is, what should we call
   layer (b)?

Suggestions include:

I. Techniques.

II. Technology-specific checkpoints.

III. Implementation strategies (or simply "strategies").

IV. Checkpoint solutions.

Observations:

As noted above in connection with guidelines 2 and 3, many of the
requirements in layer (b) are unlikely to be technology-specific;
hence it would be misleading to refer to them all as
"technology-specific checkpoints". Also, they may not be analogous to
"checkpoints" as such, especially where several alternative strategies
are given for achieving the same result.

Received on Friday, 7 September 2001 02:24:05 UTC