User Agent Accessibility Guidelines 1.0

8 July 2002

3. Conformance

This normative section defines what it means to conform to this document and explains how to make a valid conformance claim. The following are important conformance concepts.

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

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. Some requirements of this document may not benefit some users for some content, but the requirements are expected to benefit many users with disabilities, for general purpose content. For more information, please see the section on known limitations of this document, and the section on restricted functionality and conformance.

3.1 Unconditional conformance, default set of requirements

A user agent conforms unconditionally to this document if:

  1. It satisfies the default set of conformance requirements, defined to be all of the requirements of all of the provisions of all the checkpoints, as well as all of the normative inclusions and exclusions that qualify the checkpoints, and
  2. It satisfies these requirements as follows:

Note: The checkpoints outside of guideline 6 may be satisfied by assistive technologies as well, but are required by the current document to be satisfied by a conforming user agent. For example, checkpoint 9.3 involves navigation that must be possible through the user interface, not just via an API. Note that an assistive technology may be part of the subject of a claim.

3.2 Conditional conformance

To allow user agents with different capabilities to conform, and to facilitate comparisons of claims about different user agents, this document defines allows conditional conformance. A user agent conforms conditionally if it satisfies any set of requirements that results from starting with the default set of requirements and removing or adding requirements according to these steps:

  1. Choose a Conformance level; for conformance levels A or Double-A, remove requirements from the default set.
  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. If the user agent does not satisfy the requirements associated with the Events label, remove those requirements.
  4. If the user agent does not implement a selection mechanism, or if the user agent does not satisfy the requirements associated with the Selection label, remove those requirements.
  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.
  6. Remove the requirements of any checkpoints or parts of checkpoints that do not apply.

Since these steps may produce very different sets of checkpoints for different user agents, a well-formed conformance claim must indicate how the set of requirements chosen for the claim differs from the default set. The checklist [UAAG10-CHECKLIST] may prove useful when documenting the details of a conditional conformance claim.

Example of a conditional conformance requirement set

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: Identify requirements associated with content type labels.

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

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

Step 3: Identify requirements related to event handlers.

In this example, the user agent supports functionalities that promote input-device independent access to event handlers. Therefore, the claimant may rightly claim conformance for the requirements associated with the Events label.

These requirements are optional for conformance. However, if the claimant does include the events label in the claim, the associated requirements must be satisfied.

Step 4: Identify 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: Identify 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. The user agent may support partial operation through pointing device and voice input.

Step 6: Identify 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 rendered audio and animations (including video and animated images).
  2. As part of satisfying provision one, for a visual track, provide at least one setting between 40% and 60% of the original speed.
  3. As part of satisfying provision one, 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 (per [#Trespect-sync-cues]). Below 80%, the user agent is not required to render the audio track.

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:

See the section on conformance and implementing specifications for more information about identifying formats that are used to satisfy the requirements of this document.

Construct a well-formed conformance claim.

With the information gathered above, it is possible to starting building a conformance claim. A claim might include the following information:

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

3.3 Conformance details

The following normative subsections provide detail that is relevant to both unconditional and conditional conformance.

Requirements for content, for user agent features, or both user agent features and content

The requirements of certain checkpoints might apply equally well to content or to user agent user interface features. When it is necessary to remove ambiguity about the scope of a checkpoint, the checkpoint includes a label to indicate whether the requirements must be satisfied:

  1. for content only, i.e., the document object only;
  2. for user agent features only, i.e., everything that is not content (such as components of the user agent user interface, user preferences, the user agent documentation, and the user interface focus);
  3. for both content and user agent features.

Many of the content-only and rendered 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 or rendered content-only requirement with a mechanism that also involves user agent features. For instance, to satisfy checkpoint 4.7, 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.

Conformance and implementing specifications

In general, a user agent is only required to satisfy the requirements of this document for a subset of implemented specifications; these specifications must be named in a well-formed conformance claim. For example, the user agent may implement ten image formats, but a developer may only wish to claim "Image" conformance for three of them. In the well-formed claim, the developer must list the three formats used to satisfy the Image requirements. The developer is thus "rewarded" for improving user agent accessibility for three image formats.

There are several checkpoints, however, that must be satisfied for all applicable implemented specifications, otherwise the intent of the checkpoint may not be met. For instance, checkpoint 3.3 involves turning off blinking and animated text. Since there is a risk that these rendering effects may trigger seizures in people with photosensitive epilepsy, it is important that the user be able to turn them off in all cases (whether the specification is named in a conformance claim or not).

For a given conformance claim, the user agent must satisfy all checkpoints in this document for at least those specifications named in the claim (e.g., format specifications, style sheet specifications, API specifications, operating environment conventions, etc.). The user agent is not required to satisfy all checkpoints for all implemented specifications, except for the following cases:

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 checkpoint 10.2. 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, or refer to an explanation (a format specification, for example).

For some of the checkpoints in this document (checkpoints 3.3, 5.1, 5.3, and 5.5), 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 those of the operating environment).

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.7, the user agent may (but is not required to) include those controls in its own user interface.

Some of the checkpoints in this document involve operating environment conventions. When a user agent runs in more than one operating environment (e.g., a user agent implemented in Java on top of another operating system), developers may satisfy the requirements of this document by following the conventions of a single operating environment. Developers should follow the conventions that benefit accessibility most, while meeting the developers' design goals. For instance, some developers may prefer cross-platform consistency over consistency with other user agents running in a given operating environment, and this might affect which conventions would be preferred.

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, the author's content may limit the user agent's functionality for specific reasons, such as to protect intellectual property rights, 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 satisfies the requirements of this document 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. Digital rights management refers to methods of describing and perhaps enforcing intellectual property associated with Web resources.

Security considerations

Some of the requirements of this document have security implications: communication through APIs, allowing programmatic read and write access to content and user interface control, etc. This document assumes that features required by this document will be built on top of an underlying security architecture. Consequently, unless permitted explicitly in a checkpoint (as in checkpoint 6.5), this document grants no conformance exemptions based on security issues.

Consider the example of a form control that allows the user to enter a password. Graphical user agents commonly display typed characters as asterisks (or display nothing). The user agent should not communicate asterisks to assistive technologies, but the real password, properly encrypted.

Appropriate user agent behavior with respect to security (and more generally as well) also depends on the user's context. For instance, hiding typed passwords with asterisks is much less important for someone in a room alone than for someone in a crowded room. Similarly, unencrypted passwords rendered as synthesized speech should not be broadcast in a crowded room, but may pose no security risk if the user is wearing an earphone.

For information related to security, refer to "XML-Signature Syntax and Processing" [XMLDSIG] and "XML Encryption Syntax and Processing" [XMLENC].

3.4 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 synchronized speech.

3.5 Content type labels

Each content type label defines a set of requirements related to support for images, animations, video, audio, and synthesized speech.

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.6. To conform, the user agent must implement at least one image format. The user agent must satisfy these requirements for all implemented image formats; see the section on conformance and implementing specifications. The image requirements apply to content that is recognized as distinct and that, according to the encoding format, may be rendered as a coherent unit.
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, and 4.5. To conform, the user agent must implement at least one animation format. The user agent must satisfy the requirements of checkpoint 3.2 for all implemented animation formats; see the section on conformance and implementing specifications. The animation requirements apply to animation content that is recognized as distinct and that, according to the encoding format, may be rendered as a coherent unit.
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. The user agent must satisfy the requirements of checkpoint 3.2 for all implemented video formats; see the section on conformance and implementing specifications. The video requirements apply to video content that is recognized as distinct and that, according to the encoding format, may be rendered as a coherent unit.
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, and 4.8. To conform, the user agent must implement at least one audio format. The user agent must satisfy the requirements of checkpoints 3.2 and 4.7 for all implemented audio formats; see the section on conformance and implementing specifications. The audio requirements apply to audio content that is recognized as distinct and that, according to the encoding format, may be rendered as a coherent unit.
Speech
This content type label refers to all of the requirements related to synthesized speech for the following checkpoints: 4.9, 4.10, 4.11, 4.12, and 4.13. 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.6 Events label

The following checkpoints are designed to augment user agent support for event-driven behavior specified by the author: 1.2, 9.5, and 9.6. Satisfying these checkpoints will promote input device independence and thus enable users with some disabilities to make better use of content designed for a single input device (generally a pointing device). The Events label refers to the requirements of these checkpoints.

A conforming user agent is not required to satisfy these requirements. However, if a user agent does not implement these requirements, then a well-formed claim must say so.

3.7 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: 5.4, 6.6, 7.1, 9.4, 10.2, and 10.3. 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.8 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 the three input modalities of keyboard, pointing device, and voice.

3.9 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, synchronization cue, 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 (when 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.10 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/WAI/UA/WD-UAAG10-20020708.
  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, multimedia player, plug-ins, documentation, etc.). For each component, the claim must include the following:
  6. Information about which specifications have been implemented to satisfy the requirements of the document (e.g., formats, style sheet languages, APIs, operating environment conventions, etc.) The information must be sufficient to identify the specification.

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. Events label. If the user agent does not implement these checkpoints related to event handlers, the claim must say so.
  3. Selection label. If the user agent does not implement a selection mechanism, or if the user agent does not satisfy the requirements associated with the Selection label, the claim must say so.
  4. Input modality labels. Each input modality label ("Pointer" or "Voice") is an assertion that the user agent satisfies the requirements associated with the label.
  5. A list of requirements (checkpoints or portions of checkpoints) that the claimant 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. If a conformance icon is part of a claim on the Web, it must link to the W3C explanation of the icon.

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.11 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. A conformance icon does not represent that a claim is valid, only that a claim has been made. The appearance of a conformance icon does not imply that W3C has reviewed the claim.

It is inappropriate and meaningless to use a conformance icon on its own, i.e., to use the icon without an associated 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.12 Including UAAG 1.0 requirements in other specifications

Authors of technical specifications (such as W3C Recommendations) should incorporate the requirements of UAAG 1.0 as part of conformance to their specifications. This may be done by direct inclusion, or by reference using a conformance profile. Direct inclusion promotes the integration of specialized accessibility requirements; inclusion by reference is easier and less prone to error.

General advice

  1. Identify accessibility features of the specification where they are defined (see checkpoint 8.1). Optionally, create an appendix of these accessibility features as well.
  2. Remember to include user interface requirements as part of conformance to the specification. Authors of technical specifications tend to focus more on rendering or other content-related behavior and less on user interface requirements. UAAG 1.0 makes a number of user interface requirements that authors will need to consider (such as those in guideline 5 pertaining to viewport behavior).
  3. Include at least an informative reference to UAAG 1.0 and Techniques for UAAG 1.0. See the section on how to refer to UAAG 1.0 for more information.
  4. When a question arises about how a checkpoint applies for a technology, whether a term is used differently between UAAG 1.0 and the technical specification, etc. consult the User Agent Accessibility Guidelines Working Group.

For more information on designing specifications that promote accessibility, refer to W3C's "XML Accessibility Guidelines" [XAG10].

Direct inclusion of requirements

  1. Rather than include the generic UAAG 1.0 requirements, tailor them to the specification. Be specific in the requirements, and include (in context) a reference to the original UAAG 1.0 checkpoint. The following examples illustrate what is meant by direct inclusion: Note how these examples refer to the specific elements, attributes, properties, etc. of the specifications.
  2. It is better to include some UAAG 1.0 requirements in a specification than no UAAG 1.0 requirements. However, since UAAG 1.0 requirements are designed to complement one another, arbitrary selection of requirements may result in accessibility gaps. Authors are encouraged to include requirements according to the groups defined by the conformance labels.

Conformance profiles

Section G.5 of the SVG 1.0 Recommendation [SVG] states:

Additionally, an authoring tool which is a Conforming SVG Generator conforms to all of the Priority 1 accessibility guidelines from the document "Authoring Tool Accessibility Guidelines 1.0" that are relevant to generators of SVG content.

This statement requires conformance to the Authoring Tool Accessibility Guidelines as part of conformance to SVG 1.0 (for certain classes of tools). This type of "conformance requirement by reference" is also possible for UAAG 1.0. However, since conditional conformance to UAAG 1.0 can vary beyond three conformance levels, it is important for references to state precisely what is required. This is called a conformance profile.

This section explains how to create a valid conformance profile to UAAG 1.0. UAAG 1.0 does not define any (named) conformance profiles, just the mechanism for creating them.

A valid conformance profile must include the following information:

  1. The guidelines title/version: "User Agent Accessibility Guidelines 1.0".
  2. The URI of the guidelines: http://www.w3.org/WAI/UA/WD-UAAG10-20020708.
  3. The Conformance level to be satisfied: "A", "Double-A", or "Triple-A".
  4. Content type labels. The profile must include at least one content type label. The requirements associated with that label must be satisfied as part of conforming to the profile.
  5. Events label. The profile must indicate whether the requirements associated with this conformance label (related to event handlers) are part of conformance to the profile.
  6. Selection label. The profile must indicate whether the requirements associated with this conformance label (related to a selection mechanism) are part of conformance to the profile.

A valid conformance profile should include the following information:

  1. Applicability: Which checkpoints (or portions of checkpoints) do not apply for this specification. For instance, if a specification does not define "tables", the conformance profile should indicate that checkpoint 10.1 does not apply. Specification authors should include rationale in their profiles that explains why a checkpoint does not apply.

A valid conformance profile may include the following information:

  1. Input modality labels: If conformance for pointer or voice input is required in addition to keyboard input.

Note: that the following are always required and therefore need not appear in a conformance profile:

  1. Keyboard input requirements
  2. Content focus requirements (only when the content includes enabled elements; see checkpoint 9.1).

The following is an (partial) example of a valid conformance profile (expressed in plain text):

As part of conformance to MyFormat 1.0, a user agent must satisfy the following conformance profile of the "User Agent Accessibility Guidelines 1.0" [UAAG10]:

See the section on how to refer to UAAG 1.0 for what should appear in the references section of the specification.