W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > July to September 2000

Terminology

From: Jason White <jasonw@ariel.ucs.unimelb.edu.au>
Date: Tue, 15 Aug 2000 11:01:51 +1000 (EST)
To: Web Content Accessibility Guidelines <w3c-wai-gl@w3.org>
Message-ID: <Pine.SOL.4.10.10008151036040.20325-100000@ariel.ucs.unimelb.edu.au>
There is a problem of terminology which needs to be resolved.

In WCAG 1.0 the most abstract and general requirements were called
"guidelines". The more specific requirements were termed "checkpoints".

In working group discussions subsequent to the publication of the WCAG 1.0
Recommendation, it was decided to develop a three-layered hierarchy of
requirements. The first two layers were to be framed in terms that did not
invoke the capabilities or limitations of particular, existing standards
or technologies. The third layer, however, was intended to offer concrete
and, so far as possible, readily verifiable implementation requirements,
specific to particular standards or technologies (for example, HTML/CSS,
XML, SVG, Smil, the DOM etc.).

In working group deliberations surrounding these proposals, there emerged
a tendency to speak of "technology-specific checkpoints". This led to a
confusion of nomenclature, in that the term "checkpoint" thus became
ambiguous, in so far as it could apply either to the second or the third
layer of the three-tiered construction outlined above. This lack of
clarity has been facilitated by the text of WCAG 1.0, in which some of the
checkpoints are expressed in relatively general terms, whereas others are
quite specific to existing standards and technologies, most notably HTML.

Accordingly, in WCAG 2.0 it will be necessary to clarify the important
concepts around which the requirements are structured and to use
terminology in a consistent fashion. Inevitably, this will result, to some
extent, in a departure from the usage conventions adopted in WCAG 1.0, as
there are now three, rather than two, fundamental divisions along the
continuum from generality to specificity, from the abstract to the
concrete.

Proposals currently on offer:

1. To use the terms "principle", "guideline" and "checkpoint" as defined
in the current draft, thereby making an explicit departure from WCAG 1.0.

2. To use the terms "guideline", "checkpoint" and "technique" to designate
the three levels (proposed by Charles). This has strong historical roots
in the early days of the guidelines. However, "techniques" (as in the
"techniques document") have since come to be regarded not as numbered,
verifiable requirements, but as implementation strategies which are
explained and exemplified in the Techniques document. Furthermore, given
that the technology-specific requirements constitute the level at which
(manual or automated) testing is to be performed, it would seem
counter-intuitive to regard the second of the three layers (which is not
technology-specific) as checkpoints, a term which implies that these are
the criteria against which to verify compliance, whereas the more
verifiable (testable) requirements are to be called "techniques".

3. To refer to the three levels, respectively, as "principles",
"strategies" and "checkpoints" (proposed by Gregg). By designating the
second layer as "strategies", it would be implied that not all of these
requirements need be fulfilled in order for content to be accessible, but
that certain combinations of requirements under each principle need to be
met for purposes of compliance. Again (as I understand it) the
checkpoints, being technology-specific, would provide the basis for
testing, with satisfaction of certain combinations of
(technology-specific) checkpoints having been deemed to constitute
application of the strategies which in turn satisfy the requirements of
the principles of accessible design.

In conclusion, I would argue that none of the terminological options is
entirely satisfactory, all involve some departures from past practices,
and that precise definitions need to be established so they can be applied
consistently in future drafts of WCAG 2.0.

Note: the foregoing summary is intended to outline the relevant arguments
and not to indicate any preference, on my part, for one solution over
another. Specifically, I think they all have advantages and drawbacks, but
that a clear decision needs to be made by the working group.
Received on Monday, 14 August 2000 21:03:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:47:05 GMT