Re: Terminology

I still have a strong preferences for maintaing the terminology of WCAG 1,
for the following reasons..

The Guidelines specify general principles of accessibility, in a way that is
independent (more or less) of any particular technology.

The Checkpoints are the actual requirements for accessibility, although still
expressed in a way which does not presume a particular technology. These can
be verified, although doing so requires knowledge of how the requirement may
be  met by using the technology in question each time.

The techniques, however, provide specific ways of meeting the requirements
for specific technologies. As Kynn used to ask, we need to be clear about
whether a given technique meets the entirety of the requirement or not in
some cases it will others not. For example, alt attributes cannot by
themselves fulfill the requirements of WCAG 1 checkpoint 1.1 except in a
limited, albeit large, set of cases.

Otherwise we are still at the level of fundamentally approaching this from a
particular technology, and then trying to add others as we figure them out.

The approach outline is the approach taken by ATAG, which when combined with
its current dependency on WCAG 1 for a quarter of the requirements means that
testing an individual piece of software for conformance is a lot of work. On
the other hand, it has given us a set of guidelines that is as useful for
image and multimedia editing software as it is for HTML software (insofar as
the WCAG can be appropriately applied to those areas).

And it means we don't have to change terminology on people - if we are going
to shift the meanings then we should simply use completely different words,
and I do not think that is justified.

Charles McCN

On Tue, 15 Aug 2000, Jason White wrote:

  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.
  
  

-- 
--
Charles McCathieNevile    mailto:charles@w3.org    phone: +61 (0) 409 134 136
W3C Web Accessibility Initiative                      http://www.w3.org/WAI
Location: I-cubed, 110 Victoria Street, Carlton VIC 3053
Postal: GPO Box 2476V, Melbourne 3001,  Australia

Received on Monday, 14 August 2000 21:53:35 UTC