Checkpoints 2.3-2.5, 6.1 and 6.4

The following is a brief discussion, reflecting my personal opinions only,
of the checkpoints which Charles has suggested should be combined. There
is, as usual, considerable merit in his suggestion, though as is so often
the case, there are matters of detail that need to be worked out before
deciding which course of action to follow.

In guideline 2, there are two basic requirements concerned with the
representation, in markup or in a data model, of the logical structure and
semantics of content. The fundamental proposition is now stated in
checkpoint 2.5, following recent amendments to that checkpoint, viz., that
logical structure should be defined in markup or in a data model. The
question which immediately comes to mind is this: which structures, and
which semantic distinctions, need to be made explicit to the user agent or
other processing application?

Two criteria are established in the checkpoints which attempt to answer
this question. The first is based on the need for device and modality
independence: the relevant distinctions are those which will enable a
clear, accurate and complete presentation to be provided in auditory,
visual and tactile media. Yet, this criterion raises more questions than
it resolves, unless one happens to be familiar with the representation of
documents (and other content) in the three modalities mentioned. Yet, this
assertion expresses, fundamentally, what needs to be achieved. Of course,
the details will be filled in, at least partially, by the techniques; but
there is also a parallel principle at work in the guidelines, the idea of
parity of media. In general, the concept is that no medium (visual,
auditory or tactile) should be privileged over the others; equal access
entails an equivalent quality of presentation in whatever medium the
reader may require. Thus, to capture this principle concretely, checkpoint
2.3 provides that if presentation is used to convey distinctions of
meaning or structure, these distinctions should also be represented in
markup so that they can be reflected in presentations generated in other
modalities. This provides a minimum standard against which to judge the
adequacy of markup: if all of the structural features that are clearly
evident in one's preferred (or custom designed, e.g., with style sheets)
presentation, then they should also be expressed in the markup. Where this
test is inapplicable, we fall back upon the more general requirement which
captures the underlying goal, namely (in 2.5) that a high quality of
presentation in the three designated modalities is required, and decisions
as to what markup to use should be made with that end clearly in mind.

Of course, there are significant distinctions which may not be obvious
from the author's presentation, if there is one. For instance, language
changes may not be represented in a printed text, but they are necessary
to enable a spoken or braille rendering. Also, the precise boundaries of
sections are normally implied from the heading styles used, but are not
indicated explicitly in visual formatting. This is why checkpoint 2.5, as
currently formulated, notes that additional distinctions (to those arising
under checkpoint 2.3) may be needed to permit, or enhance, presentation in
different modalities. Checkpoint 2.4 is a direct consequence of checkpoint
2.3, and is retained due to its importance and its ancestry in WCAG 1.0.

Thus, we need to ensure that all of these considerations are adequately
addressed in whatever wording we propose to adopt in seeking to combine,
or rewrite, these checkpoints.

Checkpoints 6.1 and 6.4 provide another interesting case. As Charles has
noted, 6.4 is a means of satisfying 6.1. Should it be reduced to a
technique? It is a general requirement, by no means technology-specific,
and of considerable importance, militating against the conclusion that it
ought to be relegated to the techniques. However, 6.1 can not readily be
eliminated either, for it covers cases which are not contemplated by 6.4.
To take an example, an HTML document can be designed so that it will
continue to be usable if the supplied style sheet is not applied. This
does not involve creating an alternative version of the content. 6.4
envisages circumstances in which the author needs to supply a
transformation, style sheet, programme or whatever may be necessary, to
enable the user agent to process the data format in which the content is
supplied. I agree with Charles that the two requirements are closely
related. Perhaps 6.4 could be turned into a note that we could place
immediately after the text of checkpoint 6.1. Likewise, perhaps we could
reverse the order of checkpoints 2.3 and 2.5, and introduce 2.4 as a note
under checkpoint 2.3 (this reduces three checkpoints to two, while
retaining the importance of the ideas expressed in 2.3 or 2.5). Of course,
2.5 could be converted into a note as well, but I think notes should be
used to communicate subsidiary points or ideas, and that fundamental
requirements or concepts deserve to be included as separate checkpoints.

If possible, please consider these issues in preparation for the meeting
so that relevant proposals can be put forward and discussed.

Received on Thursday, 12 October 2000 01:18:23 UTC