Notes on WCAG 2.0: sufficiency/checkpoint satisfaction? criteria

The following are just brief notes and comments, marked up in HTML for convenience.

Guideline 1

Checkpoint 1.1 criteria:

  1. To each auditory, graphical or multimedia presentation there must correspond a text equivalent.
  2. 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.
  3. 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 suffice.

Checkpoint 1.2. The sufficiency criteria of checkpoint 1.1 apply, subject to the following:

  1. All significant scenes, actions and events in the multimedia presentation must be described.
  2. All significant dialogue and sounds within the multimedia presentation must be captioned.
  3. 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 general way).

Checkpoint 1.3. The criteria specified with respect to checkpoint 1.2 apply, but in addition:

  1. 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).

Checkpoint 1.4:

  1. The hierarchical structure of the content (see examples already in guidelines) must be unambiguously represented in the markup or data model.
  2. 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.

Checkpoint 1.5:

  1. 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 table.
  2. 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 sheet.

Guideline 2

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:

  1. An index/site map/table of contents
  2. An overview describing the site's scope and purpose, with links to relevant parts of the content.
  3. A search facility.

Checkpoint 2.2. Where you provide hypertext links, form controls or other interactive content that creates a user interface:

  1. The logical placement of user interface controls must, where possible, be consistent within your web site as a whole.
  2. Form controls and other user interface components must be labeled with consistent terminology.
  3. Where practicable, operating system or application conventions likely to be familiar to the user should be followed.
  4. Any unusual user interface features or behaviours that are likely to confuse the first-time user, must be clearly documented.

Checkpoint 2.3. Where user agents do not provide control over such mechanisms (see techniques documents for discussion of user agent support):

  1. 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.
  2. Such a user interface must be clearly identified on, and accessible from, the home or primary page of a mutli-document web site.
  3. 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):

  1. 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 pointing device.
  2. 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.

Guideline 3

Checkpoint 3.1:

  1. 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:

  1. 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).
  2. 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!

  1. 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.
  2. 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.

Checkpoint 3.4:

  1. Illustrations must be designed to portray important concepts or relationships employed in the content.
  2. 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 illustration.

Checkpoint 3.5: Where a yet to be defined complexity threshhold is exceeded:

  1. Provide a summary which clearly conveys the main ideas or relationships expressed in the content.
  2. Where the markup or data model allows, the summary should be associated explicitly with the content that it is intended to summarize.

Checkpoint 3.6:

  1. 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 defined.
  2. 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.

Guideline 4

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:

  1. Text equivalents (including, where applicable, synchronization and/or auditory descriptions);
  2. The provision of logical structure in markup or in a data model;
  3. The logical separation of structure and content from presentation;
  4. 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:

  1. 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.

  1. 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.

Notes

  1. 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.
  2. The order of checkpoints 3.1 and 3.2 should be reversed.
  3. I have used the words must and should with care: the former refers to a criterion which, in the author's judgment, must be met in order to satisfy a WCAG 2.0 checkpoint; the latter to additional functionality that may, but need not, be provided. In many checkpoints however, there are only requirements; and thus we may need to consider whether to divide the criteria into checkpoint conformance requirements, stricto sensu and non-normative (sufficiency) examples--conditions that may be satisfied.