User Agent Accessibility Guidelines 1.0

22 June 2001

3. Conformance

This normative section defines what it means to conform to this document and explains how to make a valid conformance claim. Please note that this document includes both conformance requirements and conformance claim requirements.

Here is a sample claim (expressed in HTML):

<p>On 22 June 2001, Project X (version 2.3) running on MyOperatingSystem (version 4.2) conforms to <abbr title="the World Wide Web Consortium">W3C</abbr>'s "User Agent Accessibility Guidelines 1.0", http://www.w3.org/TR/2001/WD-UAAG10-20010622, level Double-A. Unsupported content types: Video, Speech. Unsupported input modalities: Voice. (see section 3.1 of the UAAG 1.0). The <a href="http://example.com/checkpoints">list of checkpoints that do not apply</a> is available online.</p>

In this document (notably in the checkpoints and in this section on conformance), the terms "must", "should", and "may" (and related terms) are used in accordance with RFC 2119 [RFC2119]. This section uses the expression "subject of a claim" to refer to a user agent about which someone wishes to claim some level of conformance to this document. The subject of a claim may be one or more software components (e.g., a browser plus additional software).

Note: Conformance to the requirements of this document is expected to be a strong indicator of accessibility, but it is neither a necessary nor sufficient condition for ensuring the accessibility of software. Some software may not conform to this document but still be accessible to some users with disabilities. Conversely, some software may conform to this document but still be inaccessible to some users with disabilities. Please refer to the section on known limitations of this document.

3.1 Conformance model

The conformance model of this document has been designed to allow different types of user agents with different input and output capabilities to conform. At the same time, the model is designed so that:

The conformance model works as follows:

A user agent conforms conditionally if it satisfies any set of requirements that results from following these steps:

  1. Choose a conformance level. Each conformance level corresponds to a set of checkpoints (and thus a set of requirements).
  2. Remove the requirements associated with any unsupported content type labels. In order to conform conditionally, a user agent must satisfy the requirements of at least one content type label.
  3. Remove the requirements of any checkpoints or parts of checkpoints that do not apply.
  4. If the user agent does not implement a selection mechanism, remove the requirements of any checkpoints or parts of checkpoints associated with the selection label.
  5. Add requirements associated with any supported input modality label. Note: In the default set of requirements, the only input device requirements relate to keyboard input.

Example of how to determine conformance requirements

The following example illustrates how to apply the above steps to determine which requirements must be satisfied for conformance, and what would be required as part of a well-formed conformance claim. This informative example does not illustrate a complete user agent evaluation.

Consider a user agent with these capabilities:

Step 1: Choose a conformance level.

The claimant wishes to conform at level Double-A. This establishes a set of requirements consisting of all of the requirements of all the priority 1 and 2 checkpoints.

Step 2: Remove the requirements associated with any unsupported content type labels.

The claimant wishes to claim conformance for the user agent's support of text, images, audio, and video. The claimant does not wish to claim conformance for other animation formats.

The following content type labels are therefore relevant: VisualText, ColorText, Image, Animation, Video, and Audio. This means that:

Step 3: Remove the requirements of any checkpoints or parts of checkpoints that do not apply.

Consider checkpoint 4.4, for example, which is associated with both the Audio and Animation content type labels:

4.4 Slow multimedia. (P1)
  1. Allow the user to slow the presentation rate of audio and animations (including video and animated images).
  2. For a visual track, provide at least one setting between 40% and 60% of the original speed.
  3. For a prerecorded audio track including audio-only presentations, provide at least one setting between 75% and 80% of the original speed.
  4. When the user agent allows the user to slow the visual track of a synchronized multimedia presentation to between 100% and 80% of its original speed, synchronize the visual and audio tracks. Below 80%, the user agent is not required to render the audio track.
  5. The user agent is not required to satisfy this checkpoint for audio and animations whose recognized role is to create a purely stylistic effect.

Suppose that:

  1. The claimant wishes to claim support for the two image formats, the one audio format, and the one video format;
  2. The claimant does not wish to claim support for the other two animation formats (e.g., because the user agent doesn't satisfy the requirements of checkpoint 4.4 for those animation formats);
  3. The user agent does not implement any synchronized multimedia formats.

The resulting applicable requirements from this checkpoint would be:

The following requirements would not apply:

Step 4: Add requirements related to the selection.

In this example, since the user agent implements a selection mechanism, it must satisfy the requirements associated with the selection label.

Step 5: Add requirements associated with any supported input modality label.

In this example, the claimant does not wish to claim conformance for complete operation for pointing device or voice input, so no requirements are added.

Construct a well-formed conformance claim.

The following information is an excerpt of that required for a well-formed claim:

The user agent does not conform unconditionally, therefore, the claim must also include the following information (excerpted from a complete claim):

3.2 Conformance levels

Each conformance level defines a set of requirements, based on priority.

Note: Conformance levels are spelled out in text (e.g., "Double-A" rather than "AA") so they may be understood when rendered as speech.

3.3 Content type labels

Each content type label defines a set of requirements related to support for images, video, animations generally, visually displayed text (in color), and synthesized speech.

VisualText
This content type label refers to all of the requirements related to the visual rendering of text for the following checkpoints: 3.3, 4.1, and 4.2.
ColorText
This content type label refers to all of the requirements related to text foreground and background color for the following checkpoint: 10.4.
Image
This content type label refers to all of the requirements related to images (excluding animated images) for the following checkpoints: 3.1, and 3.7. To conform, the user agent must implement at least one image format.
Animation
This content type label refers to all of the requirements related to animations (including video and animated images) for the following checkpoints: 3.2, 4.4, 4.5, 4.7, and 4.8. To conform, the user agent must implement at least one animation format.
Video
This content type label refers to all of the requirements related to video for the following checkpoints: 2.5, 2.6, and 3.2. To conform, the user agent must implement at least one video format.
Audio
This content type label refers to all of the requirements related to audio for the following checkpoints: 2.5, 2.6, 3.2, 4.4, 4.5, 4.7, 4.8, 4.9, 4.10, and 4.11 To conform, the user agent must implement at least one audio format.
Speech
This content type label refers to all of the requirements related to synthesized speech for the following checkpoints: 4.12, 4.13, 4.14, 4.15, and 4.16. To conform, the user agent must support synthesized speech.

Note: Some of the labels above require implementation of at least one format (e.g., for images). This document does not require implementation of specific formats, (e.g., PNG [PNG] versus SVG [SVG] for images). However, please see the requirements of checkpoint 8.2.

3.4 Input modality labels

Each input modality label defines a set of requirements related to support for pointing device and voice input. Input device requirements in this document are either stated generically (e.g., "input configuration" requirements) or as keyboard-specific requirements (e.g., "keyboard API").

Pointer
This input modality label refers to all of the input device requirements of this document, applied to pointing device input. For keyboard-specific requirements, substitute "pointing device input" for "keyboard." The set of pointing device input requirements does not include the requirements of checkpoint 11.4.
Voice
This input modality label refers to all of the input device requirements of this document, applied to voice input. For keyboard-specific requirements, substitute "voice input" for "keyboard." The set of voice input requirements does not include the requirements of checkpoint 11.4.

Note: Developers are encouraged to design user agents that are at least partially operable through all three input modalities.

3.5 Selection label

This document does not require the user agent to implement a selection mechanism in order to conform. However, if the user agent does implement a selection mechanism, in order to conform it must satisfy the relevant portions of the following checkpoints: 6.5, 7.1, 9.4, 10.2, 10.3, and 5.4. The Selection label refers to the selection requirements of these checkpoints.

If a user agent does not implement a selection mechanism, then a well-formed claim must say so.

Note: This document does require implementation of both content focus and user interface focus; see checkpoint 9.1 and checkpoint 9.2.

3.6 Checkpoint applicability

A checkpoint (or part of a checkpoint) applies unless any one of the following conditions is met:

  1. The checkpoint makes requirements for graphical user interfaces or graphical viewports and the subject of the claim only has audio or tactile user interfaces or viewports.
  2. The checkpoint refers to a role of content (e.g., transcript, captions, associated conditional content, fee link, synchronization cue, client-side redirect, purpose of a table, etc.) that the subject of the claim cannot recognize because of how the content has been encoded in a particular format. For instance, HTML user agents can recognize "alt", OBJECT content, or NOFRAMES content as specified mechanisms for conditional content. HTML user agents are not expected to recognize that a nearby paragraph is a text equivalent for the image (though not marked up as such).
  3. The checkpoint requires control of a content property that the subject cannot recognize because of how the content has been encoded in a particular format. Some examples of this include:

3.7 Well-formed conformance claims

A claim is well-formed if meets the following conditions.

Condition 1: The claim must include the following information:

  1. The date of the claim.
  2. The guidelines title/version: "User Agent Accessibility Guidelines 1.0".
  3. The URI of the guidelines: http://www.w3.org/TR/2001/WD-UAAG10-20010622.
  4. The conformance level satisfied: "A", "Double-A", or "Triple-A".
  5. Information about the subject. The subject of the claim may consist of one or more software components (e.g., a browser plus a multimedia player plus a plug-in). For each component, the claim must include the following:

Condition 2: The claim must include the following information if the user agent conforms conditionally:

  1. Content type labels. Content type labels are used in assertions that the subject either (1) does not satisfy the requirements associated with the label (e.g., for a specific checkpoint, for any checkpoint, etc.), or (2) does satisfy the requirements associated with the label (e.g., for a particular format when satisfying the requirements of a checkpoint). In order to conform conditionally, a user agent must satisfy the requirements of at least one content type label.
  2. Input modality labels. Each input modality label ("Pointer" or "Voice") is an assertion that the user agent satisfies the requirements associated with the label.
  3. Selection label. If the user agent does not implement a selection mechanism, the claim must say so.
  4. A list of requirements (checkpoints or portions of checkpoints) that the claim asserts do not apply.

Condition 3: At least one version of the claim must conform to the "Web Content Accessibility Guidelines 1.0" [WCAG10], level A. This claim may appear on the Web, on a CD-ROM, etc.

A well-formed claim should also include the following information:

This specification imposes no restrictions on the format used to make a well-formed claim. For instance, the claim may be marked up using HTML (see sample claim), or expressed in the Resource Description Framework (RDF) [RDF10].

3.8 Validity of a claim

A conformance claim is valid if the following conditions are met:

  1. The claim is well-formed.
  2. It is verified that the user agent satisfies the default set of requirements, in addition to (or except) those requirements added (or exempted) by the allowable mechanisms: conformance levels, content type labels, input modality labels, and applicability.

It is not currently possible to validate a claim entirely automatically.

Notes:

Responsibility for claims

This specification imposes no restrictions about:

Claimants (or relevant assuring parties) are solely responsible for the validity of their claims, keeping claims up to date, and proper use of the conformance icons. As of the publication of this document, W3C does not act as an assuring party, but it may do so in the future, or it may establish recommendations for assuring parties.

Claimants are expected to modify or retract a claim if it may be demonstrated that the claim is not valid. Claimants are encouraged to claim conformance to the most recent User Agent Accessibility Guidelines Recommendation available.

Conformance icons

As part of a conformance claim, people may use a conformance icon (or, "conformance logo") on a Web site, on user agent packaging, in documentation, etc. Each conformance icon (chosen according to the appropriate conformance level) used on the Web must link to the W3C explanation of the icon. The appearance of a conformance icon does not imply that W3C has reviewed or validated the claim. An icon must be accompanied by a well-formed claim.

Draft Note: In the event this document becomes a W3C Recommendation this document will link to the W3C Web site for additional information about the icons and how to use them.

3.9 Additional conformance topics

The following sections describe additional conformance requirements and exemptions.

Conformance and implementing specifications

User agents may conform (both unconditionally and conditionally) by satisfying the the specification requirements of this document for some, but not all, implemented specifications and APIs. For example, a developer may implement ten image formats but only wish to claim "Image" conformance for three of them.

In particular, the following requirements may be satisfied for some but not all implemented specifications:

Requirements for content, user agent features, or both

Each checkpoint definition indicates whether the requirements of the checkpoint must be satisfied by the subject of the claim for:

  1. content only, i.e., the document object.
  2. user agent features only, i.e., everything besides the document object (e.g., components of the user agent user interface, the user agent documentation, and the user interface focus).
  3. both content and user agent features.

Many of the content-only requirements also make sense for the user agent user interface (e.g., allow the user to render blinking text as motionless text). User agent developers are encouraged to consider the content-only requirements when designing the user agent's user interface.

The user agent may satisfy a "content only" requirement with a mechanism that also involves user agent features. For instance, to satisfy checkpoint 4.9, the user agent may provide a single control for all volume (including content and user interface features). Similarly, to satisfy checkpoint 3.3, the user agent may offer a single configuration that turns off blinking in both content and the user interface.

Note. Depending on the checkpoint, content focus and selection requirements may have any of the three labels. Content focus and selection are "state variables" that straddle both worlds of content and user agent user interface.

Configuration requirements

The user agent may satisfy the configuration requirements of this document through configuration files (e.g., profiles, initialization files, themes, etc.). For instance, style sheets might be used as a mechanism to satisfy the highlight and configuration requirements of checkpoints 10.2 and 10.4. Any functionality that is configurable through a configuration file should also be configurable through the user agent user interface. Furthermore, if configuration files may be edited by hand, the user agent documentation should explain the configuration file format.

For some of the checkpoints in this document (checkpoint 3.3, checkpoint 5.1, checkpoint 5.3, checkpoint 5.5, checkpoint 5.6), configuration is preferred, but not required to satisfy the checkpoint in some circumstances. For other checkpoints, the configuration requirement is considered as important as the functionality being configured.

Since this document allows conformance by multiple software components (e.g., a browser, a media player, and several plug-ins), there are likely to be times when, to satisfy the configuration requirements of the document, each component has to provide for configuration independently. To make configuration easier for the user, components should share and inherit configurations (including from the operating environment).

Requirements satisfied through user interface or API

The requirements of guideline 6 must be satisfied by implementing APIs.

The requirements of the other guidelines must be satisfied by at least one mechanism other than an API. These requirements are not meant to be satisfied by assistive technologies (unless those technologies are part of a conformance claim). For example, checkpoint 9.3 involves navigation that must be possible through the user interface, not just via an API.

Use of operating environment features as part of conformance

To satisfy the requirements of this document, developers are encouraged to adopt operating environment conventions and features that benefit accessibility. When an operating environment feature (e.g., the operating system's audio control feature, including its user interface) is adopted to satisfy the requirements of this document, it is part of the subject of the claim.

Developers may provide access through the user agent's user interface to operating environment features adopted to satisfy the requirements of this document. For example, if the user agent adopts the operating system's audio control feature to satisfy checkpoint 4.9, the user agent may (but is not required to) include those controls in its own user interface.

Restricted functionality and conformance

User agents do not conform to this document on a per-resource basis; claims are not as specific as "the user agent conforms for this particular Web page." A user agent conforms if it satisfies the requirements of this document for most general-purpose content, in ordinary operating conditions.

In some cases, an author may wish to limit the user agent's functionality for specific reasons, such as to protect intellectual property rights, for security reasons, or to provide a read-only view (allowing no user interaction). Content that limits the functionality of the user agent in some cases does not automatically invalidate a conformance claim. A valid conformance claim remains valid as long as the user agent is capable of satisfying the requirements of the document (i.e., the functionalities have been implemented), and does so for most general-purpose content.

Note: The User Agent Accessibility Guidelines Working Group recognizes that further work is necessary in the area of digital rights management as it relates to accessibility.