Notes on WCAG 2.0: sufficiency criteria
The following are just brief notes and comments, marked up in HTML
Checkpoint 1.1 requirements:
- To each auditory, graphical or multimedia presentation there
must correspond a text equivalent.
- The text equivalent must be associated explicitly with
the auditory or graphical presentation to which it corresponds,
either in markup, in a data model accessible to the user agent,
or via a hypertext link.
- The text equivalent must, so far as possible, fulfil the same
function and convey the same information, in context, as the
non-text presentation. Where this is not possible, that is, where
the non-text presentation cannot be described in words (e.g. the
case of artwork, music etc., such as Beethoven's fifth symphony
as in Gregg's example) a label identifying the content will
Checkpoint 1.2. The sufficiency criteria of checkpoint 1.1 apply,
subject to the following:
- All significant scenes, actions and events in the multimedia
presentation must be described.
- All significant dialogue and sounds within the multimedia
presentation must be captioned.
- Descriptions and captions must be synchronized with the events
they describe to within a tolerance of (whatever the standard
is, whether it be measured in seconds or specified in a more
Checkpoint 1.3. The criteria specified with respect to checkpoint
1.2 apply, but in addition:
- So far as possible, the auditory description should be
integrated into pauses in the dialogue of multimedia
presentations, and should, where possible, avoid obscuring
important sounds. (I haven't had much experience with auditory
descriptions of multimedia, but I think this is the basic idea).
- The hierarchical structure of the content (see examples already
in guidelines) must be unambiguously represented in the markup
or data model.
- Important non-hierarchical relationships, such as
cross-references, or the correspondence between header and data
cells in a table, must be represented unambiguously in the
markup or data model.
- There must be sufficient markup, or a sufficient data model, to
ensure that a logical, linear reading order can be derived from the
content. For example, it must be possible automatically to
distinguish the columns of a multi-column document and to
identify the association between header and data cells in a
- To the extent that the technology allows (see checkpoint
solutions) the markup or data model representing the structure
of the content, must be logically separated from the
presentation, either in separate data structures or in a style
Checkpoint 2.1 (as proposed in current draft). If the web site involves more than x documents, or meets some
other complexity threshold yet to be defined, then at least one
of the following must be provided:
- An index/site map/table of contents
- An overview describing the site's scope and purpose, with links
to relevant parts of the content.
- A search facility.
Checkpoint 2.2. Where you provide hypertext links, form controls or
other interactive content that creates a user interface:
- The logical placement of user interface controls must, where
possible, be consistent within your web site as a whole.
- Form controls and other user interface components must be
labeled with consistent terminology.
- Where practicable, operating system or application conventions
likely to be familiar to the user should be followed.
- Any unusual user interface features or behaviours that are
likely to confuse the first-time user, must be clearly
Checkpoint 2.3. Where user agents do not provide control over such
mechanisms (see techniques documents for discussion of user agent support):
- A form or other user interface must be provided through which
the user can elect to deactivate processes or features that
cause extreme changes in context.
- Such a user interface must be clearly identified on, and
accessible from, the
home or primary page of a
mutli-document web site.
- It must be possible to access such a user interface, via the
home page and any intermediate pages, without triggering
unexpected changes in context.
Checkpoint 2.4: Analogous to checkpoint 2.3. If we change 2.4 (and
possibly 2.3 as well) in accordance with Gregg's proposal, then an
absolute minimum (Gregg suggested 10 seconds) time-out period would be
specified, and it would be made clear that time-outs are only
permitted under exceptional circumstances.
Checkpoint 2.5. Where device-independent event handlers are
provided by the API, and the desired user interaction, or its effects,
can be described in words (Gregg's qualification drawn from US regulations):
- Generic event handlers (e.g., focus events, activations
etc.), are to be used in preference to event handlers that require or assume a
specific kind of input device, for example a keyboard or
- The use of device-specific event handlers to customize the user
interface, in circumstances where device-independent event
handlers are specified as well, does not constitute a violation
of this checkpoint.
- Each type of structural element occurring in the logical structure of the content (see
checkpoint 1.4), for example headings, tables, user interface
controls etc., must be
presented using the same formatting and layout conventions
throughout a document or web site, as the case may be.
Checkpoint 3.2. With respect to each media type (in the CSS sense,
e.g., screen, print, aural) for which you provide style sheets or
other control over presentation:
- Each type of structural element (see checkpoint 1.4) occurring
in the logical structure of the content, must be reflected in
the presentation via a specific style or combination of style
properties (this terminology does not imply that style sheets
must be used, but only that specific and identifiable style
properties be associated with each type of structural element).
- The place of a structural element within the hierarchy (e.g.,
the level of a heading within a document), where this
information is significant in conveying the over-all structure
of the content, must be assigned a distinct style.
Checkpoint 3.3. Here we go!
- The language used must be no more complex than that which
members of the intended audience can be reasonably expected to
comprehend. In identifying the intended audience, consideration
should be given to the range of educational levels and
anticipated background of individuals who are likely to be
interested in reading the content, to the level of detail at
which you propose to provide the information.
- Terminology which may not be familiar to members of the intended
audience, and which may create obstacles to understanding, must
be clearly explained and defined.
- Illustrations must be designed to portray important concepts or
relationships employed in the content.
- Where appropriate, illustrations should be referred to in the text (e.g., in a
caption or as part of the textual exposition), to provide the
reader with an appropriate context in which to interpret the
Checkpoint 3.5: Where a yet to be defined complexity threshhold is exceeded:
- Provide a summary which clearly conveys the main ideas or
relationships expressed in the content.
- Where the markup or data model allows, the summary should be
associated explicitly with the content that it is intended to summarize.
- Abbreviations, acronyms and terms which occur frequently in the
content, or which need to be understood in order to comprehend
the main concepts or ideas expressed in the content, must be
- Where the markup or data model permits, the abbreviations/acronyms
and their expansions, and the terms and their definitions,
respectively, must be explicitly associated with each other.
Where the size of a unit according to some ill-defined complexity
threshold is too great, it must be divided up. This is really vague.
Checkpoint 4.1. In comparing alternative formats, API's, protocols etc., with
which to implement content, preference must be given to those
which provide features that directly support the requirements
set forth in these guidelines. To satisfy this checkpoint,
technologies must be chosen which, of the technologies under
consideration, best support as many of the following as are applicable:
- Text equivalents (including, where applicable, synchronization
and/or auditory descriptions);
- The provision of logical structure in markup or in a
- The logical separation of structure and content from
- Device-independent event handlers.
Checkpoint 4.2: Refer to the conformance requirements of the
specification in question. In particular, if there is a formal grammar
(e.g., a document type definition or schema) or other definition of
conformance, this must be satisfied.
Checkpoint 4.3: See the checkpoint solutions and techniques for
discussion of specific cases. In general:
- API's, user interface components etc., must be chosen which are
known to be compatible with assistive technologies, in
accordance with any usage conventions (e.g., of the operating
system or application framework) which are documented as being
required in order to provide such compatibility.
Checkpoint 4.4. There is little that I can add to the checkpoint
itself, which prescribes exactly what is needed. Examples will help to
clarify what is required.
- It must be possible for a conforming user agent that supports
the format(s) in which the content is written, to render it, or
create the necessary user interaction (e.g., a form) when the
features under consideration, either individually or in
combination, are turned off or not supported.
- An additional checkpoint should be defined under guideline 1 to
address semantic elements of content which are not
structural, but which need to be provided in markup or a data model.
Natural language changes and emphasis are the two examples which have
been discussed at recent meetings.
- The order of checkpoints 3.1 and 3.2 should be reversed.
- I have used the words must and should with
care: the former refers to a sufficiency requirement, the latter
to additional functionality that may, but need not, be provided.
In many checkpoints however, there are only sufficiency
requirements; and thus we may need to consider whether to divide
the criteria into sufficiency requirements, stricto sensu and extra conditions that may be
satisfied (as the authoring tool working group has done).