W3C

Implementation Report for User Agent Accessibility Guidelines 1.0

W3C Working Draft 21 January 1999

This version:
http://www.w3.org/WAI/UA/WD-UAAG10-IMP-20000121
Latest version:
http://www.w3.org/WAI/UA/UAAG10-IMP
Previous version:
http://www.w3.org/WAI/UA/2000/01/wai-ua-implementation-20000112.html
Editors:
Jon Gunderson, University of Illinois at Urbana-Champaign
Ian Jacobs, W3C

Abstract

This document describes the implementation status of checkpoints defined in "User Agent Accessibility Guidelines 1.0". It is meant to demonstrate that the requirements specified in the guidelines can be implemented in existing and future user agents.

There is no implied or presumed endorsement of one type of implementation or another type of implementation by reference in this document. Inclusion serves only as an example to developers of the viability of satisfying the requirements of a checkpoint.

This document is part of a series of accessibility documents published by the Web Accessibility Initiative (WAI).

Status of this document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

This document has been created as support material for the User Agent Guidelines 1.0 Candidate Recommendation [ URI not yet available]. This document is not meant to become a W3C Recommendation, but should be updated as more information about implementations that satisfy the guidelines becomes available.

This is a W3C Working Draft for review by W3C Members and other interested parties. It is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". This is work in progress and does not imply endorsement by, or the consensus of, either W3C or participants in the WAI User Agent (UA) Working Group.

Please send comments about this document to the public mailing list w3c-wai-ua@w3.org (public archives).

This document has been produced as part of the Web Accessibility Initiative. The goals of the User Agent Working Group are described in the charter. A list of the Working Group participants is available.

A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.

Table of Contents


1. Introduction

The implementation examples indicate that a checkpoint has already been fully or practically implemented by some type of user agent. For checkpoints with no known implementation examples the User Agent Techniques Document provides potential solutions and ideas to developers.

Note: The implementation examples here are not an exhaustive list, but represent user agents known to the working group

1.1 Checkpoints that Require Developer Information

Most users will be able to verify that most checkpoints have been satisfied. However, verification that certain checkpoints have been satisfied may be difficult for anyone other than the developer. These checkpoints are labeled difficult.

Detailed knowledge of the user agent functionality and the operating system APIs and resources used to implement a feature is typically needed to test these checkpoints. People other than developers may be able to verify conformance through interaction with native features of the user interface and compatibility testing with assistive technology. But in these cases the person may not have knowledge of all the functionalities of the user agent or be able to test with all assistive technologies. In the case of assistive technologies it may not be clear if the detected problems reside in the user agent using appropriate interfaces to export information or the assistive technology not taking advantage of information that the user agent is making available.

1.2 Priorities

Each checkpoint in this document is assigned a priority that indicates its importance for users with disabilities.

[Priority 1]
This checkpoint must be satisfied by user agents, otherwise one or more groups of users with disabilities will find it impossible to access the Web. Satisfying this checkpoint is a basic requirement for enabling some people to access the Web.
[Priority 2]
This checkpoint should be satisfied by user agents, otherwise one or more groups of users with disabilities will find it difficult to access the Web. Satisfying this checkpoint will remove significant barriers to Web access for some people.
[Priority 3]
This checkpoint may be satisfied by user agents to make it easier for one or more groups of users with disabilities to access information. Satisfying this checkpoint will improve access to the Web for some people.

2. User Agent Accessibility Guidelines

Guideline 1. Support input and output device-independence

Checkpoints for user interface accessibility:

1.1 Ensure that every functionality available through the user interface is also available through every input device API supported by the user agent. Excluded from this requirement are functionalities that are part of the input device API itself (e.g., text input for the keyboard API, pointer motion for the pointer API, etc.) [Priority 1]
Note. The device-independence required by this checkpoint applies to functionalities described by the other checkpoints in this document (e.g., installation, documentation, user agent user interface configuration, etc.). This checkpoint does not require user agents to use all operating system input device APIs, only to make the software accessible through those they do use.

Difficult

Techniques for checkpoint 1.1
1.2 Use the standard input and output device APIs of the operating system. [Priority 1]
Do not bypass the standard output APIs when rendering information (e.g., for reasons of speed, efficiency, etc.). For example, do not bypass standard APIs to manipulate the memory associated with rendered content, since screen review utilities monitor rendering through the APIs.

Difficult

No implementation information available.

Techniques for checkpoint 1.2
1.3 Ensure that the user can interact with all active elements in a device-independent manner. [Priority 1]
For example, users who are blind or have physical disabilities must be able to activate text links, the links in a client-side image map, and form controls without a pointing device. Note. This checkpoint is an important special case of checkpoint 1.1.

Difficult

Techniques for checkpoint 1.3
1.4 Ensure that every functionality available through the user interface is also available through the standard keyboard API. [Priority 1]
Note. This checkpoint is an important special case of checkpoint 1.1. The comment about low-level functionalities in checkpoint 1.1 applies to this checkpoint as well. Refer also to checkpoint 10.8.

Difficult

Techniques for checkpoint 1.4
1.5 Ensure that the user interface provides information through redundant output modes. [Priority 1]
Note. For example, if a sound is used to indicate a change to the user, provide that information as text and graphical information as well. Refer also to checkpoint 5.4.

Difficult

No implementation information available.

Techniques for checkpoint 1.5

Guideline 2. Ensure user access to all content

Checkpoints for content accessibility:

2.1 Ensure that the user has access to all content, including alternative equivalents for content. [Priority 1]

Difficult

Techniques for checkpoint 2.1
2.2 For presentations that require user interaction within a specified time interval, allow the user to configure the time interval (e.g., by allowing the user to pause and restart the presentation, to slow it down, etc.). [Priority 1]
Techniques for checkpoint 2.2
2.3 When the author has not supplied a text equivalent for content as required by the markup language, make available other author-supplied information about the content (e.g., object type, file name, etc.). [Priority 2]
Techniques for checkpoint 2.3
2.4 When a text equivalent for content is explicitly empty (i.e., an empty string), render nothing. [Priority 3]
Techniques for checkpoint 2.4

Checkpoints for user interface accessibility:

2.5 If more than one alternative equivalent is available for content, allow the user to choose from among the alternatives. This includes the choice of viewing no alternatives. [Priority 1]
For example, if a multimedia presentation has several captions (or subtitles) available (e.g., with different levels of detail, for different reading levels, in different languages, etc.) allow the user to choose from among them.
Techniques for checkpoint 2.5
2.6 Allow the user to specify that text transcripts, captions, and auditory descriptions be rendered at the same time as the associated auditory and visual tracks. [Priority 1]
Note. Respect synchronization cues during rendering.
Techniques for checkpoint 2.6
2.7 For author-identified but unsupported natural languages, allow the user to request notification of language changes in content. [Priority 3]
Techniques for checkpoint 2.7

Guideline 3. Allow the user to turn off rendering or behavior that may reduce accessibility

Checkpoints for content accessibility:

3.1 Allow the user to turn on and off rendering of background images. [Priority 1]
Techniques for checkpoint 3.1
3.2 Allow the user to turn on and off rendering of background audio. [Priority 1]
Techniques for checkpoint 3.2
3.3 Allow the user to turn on and off rendering of video. [Priority 1]
Techniques for checkpoint 3.3
3.4 Allow the user to turn on and off rendering of audio. [Priority 1]
Techniques for checkpoint 3.4
3.5 Allow the user to turn on and off animated or blinking text. [Priority 1]
Techniques for checkpoint 3.5
3.6 Allow the user to turn on and off animations and blinking images. [Priority 1]
Techniques for checkpoint 3.6
3.7 Allow the user to turn on and off support for scripts and applets. [Priority 1]
Note. This is particularly important for scripts that cause the screen to flicker, since people with photosensitive epilepsy can have seizures triggered by flickering or flashing, particularly in the 4 to 59 flashes per second (Hertz) range.
Techniques for checkpoint 3.7
3.8 Allow the user to turn on and off rendering of images. [Priority 3]
Techniques for checkpoint 3.8
3.9 For automatic content changes specified by the author (e.g., content refresh and page forwards), allow the user to slow the rate of change. [Priority 2]
For example, alert the users to content refresh, and allow them to specify a refresh rate For example, allow the user to slow content refresh to once per 10 minutes. Or, allow the user to stop automatic refresh, but indicate that content needs refreshing and allow the user to refresh the content by activating a button or link.
Techniques for checkpoint 3.9

Guideline 4. Ensure user control of styles

Checkpoints for fonts and colors:

4.1 Allow the user to configure the size of text. [Priority 1]
For example, allow the user to specify a font family and style directly through the user agent user interface. Or, allow the user to give preferences through a user style sheet. Or allow the user to magnify text.
Techniques for checkpoint 4.1
4.2 Allow the user to configure font family. [Priority 1]
Techniques for checkpoint 4.2
4.3 Allow the user to configure foreground color. [Priority 1]
Techniques for checkpoint 4.3
4.4 Allow the user to configure background color. [Priority 1]
Techniques for checkpoint 4.4

Checkpoints for multimedia.

4.5 Allow the user to slow the presentation rate of audio, video, and animations. [Priority 1]
Techniques for checkpoint 4.5
4.6 Allow the user to start, stop, pause, advance, and rewind audio, video, and animations. [Priority 1]
Techniques for checkpoint 4.6
4.7 Allow the user to configure the audio volume. [Priority 2]
Techniques for checkpoint 4.7
4.8 Allow the user to configure the position of captions on graphical displays. [Priority 1]
Techniques for checkpoint 4.8

Checkpoints for synthesized speech:

4.9 Allow the user to configure synthesized speech playback rate. [Priority 1]
Techniques for checkpoint 4.9
4.10 Allow the user to configure synthesized speech volume. [Priority 1]
Techniques for checkpoint 4.10
4.11 Allow the user to configure synthesized speech pitch, gender, and other articulation characteristics. [Priority 2]
Techniques for checkpoint 4.11

Checkpoints for user interface accessibility:

4.12 Allow the user to select from available author and user style sheets or ignore them. [Priority 1]
Note. The browser's default style sheet is always present but may be overridden.
Techniques for checkpoint 4.12
4.13 Allow the user to configure how the selection is highlighted (e.g., foreground and background color). [Priority 1]
Techniques for checkpoint 4.13
4.14 Allow the user to configure how the content focus is highlighted (e.g., foreground and background color). [Priority 1]
Techniques for checkpoint 4.14
4.15 Allow the user to configure focus changes. [Priority 2]
For instance, allow the user to require that user interface focus not move automatically to spawned viewports
Techniques for checkpoint 4.15
4.16 Allow the user to configure user agent initiated spawned viewports, prompts, and other windows. [Priority 2]
For instance, allow the user to cancel viewport creation. Refer also to checkpoint 5.4.
Techniques for checkpoint 4.16

Guideline 5. Observe system conventions and standard interfaces

Checkpoints for content accessibility:

5.1 Provide programmatic read and write access to content by conforming to W3C Document Object Model (DOM) specifications and exporting interfaces defined by those specifications. [Priority 1]
For example, refer to DOM Levels 1 and 2 ([DOM1], [DOM2]). User agents should export these interfaces using available operating system conventions.

Difficult

Techniques for checkpoint 5.1

Checkpoints for user interface accessibility:

5.2 Provide programmatic read and write access to user agent user interface controls using standard APIs (e.g., platform-independent APIs such as the W3C DOM, standard APIs for the operating system, and conventions for programming languages, plug-ins, virtual machine environments, etc.) [Priority 1]
For example, ensure that assistive technologies have access to information about the current input configuration so that they can trigger functionalities through keyboard events, mouse events, etc.

Difficult

Techniques for checkpoint 5.2
5.3 Implement selection, content focus, and user interface focus mechanisms. [Priority 1]
Refer also to checkpoint 7.1 and checkpoint 5.2. Note. This checkpoint is an important special case of checkpoint 5.2.
Techniques for checkpoint 5.3
5.4 Provide programmatic notification of changes to content and user interface controls (including selection, content focus, and user interface focus). [Priority 1]

Difficult

Refer also to checkpoint 5.2.
Techniques for checkpoint 5.4
5.5 Ensure that programmatic exchanges proceed in a timely manner. [Priority 2]

Difficult

Techniques for checkpoint 5.5
5.6 Follow operating system conventions and accessibility settings. In particular, follow conventions for user interface design, default keyboard configuration, product installation, and documentation. [Priority 2]
Refer also to checkpoint 10.2.
Techniques for checkpoint 5.6

Guideline 6. Implement accessible specifications

Checkpoints for content accessibility:

6.1 Implement the accessibility features of supported specifications (markup languages, style sheet languages, metadata languages, graphics formats, etc.). [Priority 1]
Note. The Techniques Document [UA-TECHNIQUES] addresses the accessibility features of W3C specifications.

Difficult

Techniques for checkpoint 6.1
6.2 Conform to W3C specifications when they are appropriate for a task. [Priority 2]
For instance, for markup, implement HTML 4.0 [HTML40] or XML 1.0 [XML]. For style sheets, implement CSS ([CSS1], [CSS2]). For mathematics, implement MathML [MATHML]. For synchronized multimedia, implement SMIL 1.0 [SMIL]. For access to the structure of HTML or XML documents, implement the DOM ([DOM1], [DOM2]). Refer also to checkpoint 5.1.
Note. For reasons of backward compatibility, user agents should continue to support deprecated features of specifications. The current guidelines refer to some deprecated language features that do not necessarily promote accessibility but are widely deployed.

Difficult

Techniques for checkpoint 6.2

Guideline 7. Provide navigation mechanisms

Checkpoints for user interface accessibility:

7.1 Allow the user to navigate viewports (including frames). [Priority 1]
Note. For example, when all frames of a frameset are displayed side-by-side, allow the user to navigate among them with the keyboard. Or, when frames are accessed or viewed one at a time (e.g., by a text browser or speech synthesizer), provide a list of links to other frames. Navigating into a viewport makes it the current viewport.
Techniques for checkpoint 7.1
7.2 For user agents that offer a browsing history mechanism, when the user returns to a previous viewport, restore the point of regard in the viewport. [Priority 1]
For example, when users navigate "back" and "forth" among viewports, they should find the viewport position where they last left it.
Techniques for checkpoint 7.2
7.3 Allow the user to navigate all active elements. [Priority 1]
Navigation may include non-active elements in addition to active elements. Note. This checkpoint is an important special case of checkpoint 7.6.
Techniques for checkpoint 7.3
7.4 Allow the user to choose to navigate only active elements. [Priority 2]
Techniques for checkpoint 7.4
7.5 Allow the user to search for rendered text content, including rendered text equivalents. [Priority 2]
Note. Use operating system conventions for marking the result of a search (e.g., selection or content focus).
Techniques for checkpoint 7.5
7.6 Allow the user to navigate according to structure. [Priority 2]
For example, allow the user to navigate familiar elements of a document: paragraphs, tables and table cells, headers, lists, etc. Note. Use operating system conventions to indicate navigation progress (e.g., selection or content focus).
Techniques for checkpoint 7.6
7.7 Allow the user to configure structured navigation. [Priority 3]
For example, allow the user to navigate only paragraphs, or only headers and paragraphs, etc.
Techniques for checkpoint 7.7

Guideline 8. Orient the user

Checkpoints for content accessibility:

8.1 Make available to the user the author-specified purpose of each table and the relationships among the table cells and headers. [Priority 1]
For example, provide information about table headers, how headers relate to cells, table summary information, cell position information, table dimensions, etc. Refer also to checkpoint 5.1. Note. This checkpoint is an important special case of checkpoint 2.1.
Techniques for checkpoint 8.1
8.2 Indicate to the user whether a link has been visited. [Priority 2]
Note. This checkpoint is an important special case of checkpoint 8.4.
Techniques for checkpoint 8.2
8.3 Indicate to the user whether a link has been marked up to indicate that following it will involve a fee. [Priority 2]
Note. This checkpoint is an important special case of checkpoint 8.4. "Common Markup for micropayment per-fee-links" [MICROPAYMENT] describes how authors may mark up micropayment information in an interoperable manner. This information may be provided through the standard user interface provided the interface is accessible. Thus, any prompt asking the user to confirm payment must be accessible.
Techniques for checkpoint 8.3
8.4 Make available to the user information that will help the user decide whether to follow a link. [Priority 3]
Note. Useful information includes: whether the link designates an internal or external anchor, the type of the target resource, the length and size of an audio or video clip that will be started, and the expected natural language of target resource.
Techniques for checkpoint 8.4

Checkpoints for user interface accessibility:

8.5 Provide a mechanism for highlighting and identifying (through a standard interface where available) the current viewport, selection, and content focus. [Priority 1]
Note. This includes highlighting and identifying frames. Note. This checkpoint is an important special case of checkpoint 1.1. Refer also to checkpoint 8.4.
Techniques for checkpoint 8.5
8.6 Make available to the user an "outline" view of content, built from structural elements (e.g., frames, headers, lists, forms, tables, etc.) [Priority 2]
For example, for each frame in a frameset, provide a table of contents composed of headers where each entry in the table of contents links to the header in the document. Note. The outline view doesn't have to be navigable, but if it is, it may satisfy checkpoint 7.6.
Techniques for checkpoint 8.6
8.7 Provide a mechanism for highlighting and identifying active elements (through a standard interface where available). [Priority 2]
Note. User agents may satisfy this checkpoint by implementing the appropriate style sheet mechanisms, such as link highlighting.
Techniques for checkpoint 8.7
8.8 Allow the user to configure the outline view. [Priority 3]
For example, allow the user to configure the level of detail of the outline. Refer also to checkpoint 8.6. Refer also to checkpoint 5.2.
Techniques for checkpoint 8.8
8.9 Allow the user to configure what information about links to present. [Priority 3]
Note. Using color as the only distinguishing factor between visited and unvisited links does not suffice since color may not be perceivable by all users or rendered by all devices. Refer also to checkpoint 8.4.
Techniques for checkpoint 8.9

Guideline 9. Notify the user of content and viewport changes

Checkpoints for user interface accessibility:

9.1 Ensure that when the selection or content focus changes, it is in a viewport after the change. [Priority 2]
For example, users navigating links may navigate to a portion of the document outside the viewport, so the viewport should scroll to include the new location of the focus.
Techniques for checkpoint 9.1
9.2 Prompt the user to confirm any form submission triggered indirectly, that is by any means other than the user activating an explicit form submit control. [Priority 2]
For example, do not submit a form automatically when a menu option is selected, when all fields of a form have been filled out, or when a mouseover event occurs.
Techniques for checkpoint 9.2
9.3 Allow the user to configure notification preferences for common types of content and viewport changes. [Priority 3]
For example, allow the user to choose to be notified (or not) that a script has been executed, that a new viewport has been opened, that a pulldown menu has been opened, that a new frame has received focus, etc.
Techniques for checkpoint 9.3
9.4 When loading content (e.g., document, video clip, audio clip, etc.) indicate what portion of the content has loaded and whether loading has stalled. [Priority 3]
Techniques for checkpoint 9.4
9.5 Indicate the relative position of the viewport in content (e.g., the percentage of an audio or video clip that has been played, the percentage of a Web page that has been viewed, etc.). [Priority 3]
Note. The user agent may calculate the percentage according to content focus position, selection position, or viewport position, depending on how the user has been browsing.
Techniques for checkpoint 9.5

Guideline 10. Allow configuration and customization

Checkpoints for user interface accessibility:

10.1 Provide information to the user about current user preferences for input configurations (e.g., keyboard or voice bindings). [Priority 1]
Techniques for checkpoint 10.1
10.2 Avoid default input configurations that interfere with operating system accessibility conventions. [Priority 1]
In particular, default configurations should not interfere with the mobility access keyboard modifiers reserved for the operating system. Refer also to guideline 5.
Techniques for checkpoint 10.2
10.3 Provide information to the user about current author-specified input configurations (e.g., keyboard bindings specified in content such as by "accesskey" in HTML 4.0). [Priority 2]
Techniques for checkpoint 10.3
10.4 Allow the user to change the input configuration. [Priority 2]
For voice-activated browsers, allow the user to modify what voice commands activate functionalities Similarly, allow the user to modify the graphical user agent user interface for quick access to commonly used functionalities (e.g., through buttons).
Techniques for checkpoint 10.4
10.5 Allow the user to configure the user agent so that the user's preferred one-step operations may be activated with a single input command (keystroke, voice command, etc.). [Priority 2]
Note. User agents are not required to provide single command activation of all user agent functionalities at once, only some of them. This checkpoint is an important special case of checkpoint 10.4
Techniques for checkpoint 10.5
10.6 Follow operating system conventions to indicate the input configuration. [Priority 2]
For example, on some operating systems, if a functionality is available from a menu, the letter of the key that will activate that functionality is underlined. Note. This checkpoint is an important special case of checkpoint 5.6.
Techniques for checkpoint 10.6
10.7 Allow the user to configure the user agent through a profile. [Priority 2]
Users must be able to select from among available profiles or no profile (i.e., the user agent default settings).
Techniques for checkpoint 10.7
10.8 Provide default input configurations for frequently performed tasks. [Priority 3]
Make the most frequently operations easy to access and operable through a single command. In particular, provide convenient mappings to functionalities that promote accessibility such as navigation of links. Functionalities include being able to show, hide, resize and move graphical viewports created by the user agent.
Techniques for checkpoint 10.8
10.9 Allow the user to configure the arrangement of graphical user agent user interface controls. [Priority 3]
Techniques for checkpoint 10.9

Guideline 11. Provide accessible product documentation and help

Checkpoints for user interface accessibility:

11.1 Provide a version of the product documentation that conforms to the Web Content Accessibility Guidelines. [Priority 1]
User agents may provide documentation in many formats, but at least one must conform to the Web Content Accessibility Guidelines [WAI-WEBCONTENT]. Alternative equivalents for content, navigation mechanisms, and illustrations will all help make the documentation accessible.

Difficult

Techniques for checkpoint 11.1
11.2 Document all user agent features that promote accessibility. [Priority 1]
For example, review the documentation or help system to ensure that it includes information about the functionalities addressed by the checkpoints of this document.

Difficult

Techniques for checkpoint 11.2
11.3 Document the default input configuration (e.g., default keyboard bindings). [Priority 1]

Difficult

Techniques for checkpoint 11.3
11.4 In a dedicated section of the documentation, describe all features of the user agent that promote accessibility. [Priority 2]
Note. This is a more specific requirement than checkpoint 11.2.

Difficult

Techniques for checkpoint 11.4
11.5 Document changes between software releases. [Priority 2]
Techniques for checkpoint 11.5

3. References

For the latest version of any W3C specification, please consult the list of W3C Technical Reports.

[CHARMOD]
"Character Model for the World Wide Web", M. Dürst, 25 February 1999. This W3C Working Draft is http://www.w3.org/TR/1999/WD-charmod-19990225.
[CSS1]
"CSS, level 1 Recommendation", B. Bos, H. Wium Lie, eds., 17 December 1996, revised 11 January 1999. This CSS1 Recommendation is http://www.w3.org/TR/1999/REC-CSS1-19990111.
[CSS2]
"CSS, level 2 Recommendation", B. Bos, H. Wium Lie, C. Lilley, and I. Jacobs, eds., 12 May 1998. This CSS2 Recommendation is http://www.w3.org/TR/1998/REC-CSS2-19980512.
[CSS-ACCESS]
"Accessibility Features of CSS", I. Jacobs, J. Brewer, The latest version of this W3C Note is available at http://www.w3.org/TR/CSS-access.
[DOM1]
"Document Object Model (DOM) Level 1 Specification", V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, and L. Wood, eds. The 1 October 1998 DOM Level 1 Recommendation is http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001
[DOM2]
"Document Object Model (DOM) Level 2 Specification", L. Wood, A. Le Hors, V. Apparao, L. Cable, M. Champion, J. Kesselman, P. Le Hégaret, T. Pixley, J. Robie, P. Sharpe, C. Wilson, eds. The DOM2 specification is a Working Draft at the time of publication.
[HTML40]
"HTML 4.0 Recommendation", D. Raggett, A. Le Hors, and I. Jacobs, eds. The 24 April 1998 HTML 4.0 Recommendation is http://www.w3.org/TR/1998/REC-html40-19980424
[MATHML]
"Mathematical Markup Language", P. Ion and R. Miner, eds. The 7 April 1998 MathML 1.0 Recommendation is http://www.w3.org/TR/1998/REC-MathML-19980407
[MICROPAYMENT]
"Common Markup for micropayment per-fee-links", T. Michel, ed. The latest version of this W3C Working Draft is available at http://www.w3.org/TR/Micropayment-Markup.
[RFC2119]
"Key words for use in RFCs to Indicate Requirement Levels", S. Bradner, March 1997.
[RFC2616]
"Hypertext Transfer Protocol -- HTTP/1.1, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee, June 1999.
[SMIL]
"Synchronized Multimedia Integration Language (SMIL) 1.0 Specification", P. Hoschka, editor. The 15 June 1998 SMIL 1.0 Recommendation is http://www.w3.org/TR/1998/REC-smil-19980615
[SMIL-ACCESS]
"Accessibility Features of SMIL", M-R. Koivunen, I. Jacobs. The latest version of this W3C Note is available at http://www.w3.org/TR/SMIL-access.
[UA-CHECKLIST]
An appendix to this document lists all of the checkpoints, sorted by priority. The checklist is available in either tabular form (at http://www.w3.org/WAI/UA/CR-UAAG10-20000121/uaag10-chktable) or list form (at http://www.w3.org/WAI/UA/CR-UAAG10-20000121/uaag10-chklist).
[UA-IMPLEMENTATION]
"Implementation Report for User Agent Accessibility Guidelines 1.0 ", J. Gunderson, I. Jacobs, eds. This document describes some implementations and how they satisfy the checkpoints. The draft of the Techniques Document available at the time of this document's publication is http://www.w3.org/WAI/UA/WD-UAAG10-IMP-20000121. The latest draft of the techniques is available at http://www.w3.org/WAI/UA/UAAG10-IMP/
[UA-TECHNIQUES]
The draft of the Techniques Document available at the time of this document's publication is http://www.w3.org/WAI/UA/WD-UAAG10-TECHS-20000121. The latest draft of the techniques is available at http://www.w3.org/WAI/UA/UAAG10-TECHS/
[WAI-AUTOOLS]
"Authoring Tool Accessibility Guidelines", J. Treviranus, J. Richards, I. Jacobs, C. McCathieNevile, eds. The latest Working Draft of these guidelines for designing accessible authoring tools is available at http://www.w3.org/TR/WD-WAI-AUTOOLS/
[WAI-WEBCONTENT]
"Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, and I. Jacobs, eds. The 5 May 1999 Recommendation is http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505
[WAI-WEBCONTENT-TECHS]
"Techniques for Web Content Accessibility Guidelines 1.0", W. Chisholm, G. Vanderheiden, and I. Jacobs, eds. The latest version of this document is available at http://www.w3.org/TR/WAI-WEBCONTENT-TECHS
[WAI-WEBCONTENT-ERT]
"Techniques For Evaluation And Implementation Of Web Content Accessibility Guidelines, C. Ridpath. The latest version of this Working Draft is available at http://www.w3.org/WAI/ER/IG/ert/.
[XML]
"Extensible Markup Language (XML) 1.0.", T. Bray, J. Paoli, C.M. Sperberg-McQueen, eds. The 10 February 1998 XML 1.0 Recommendation is http://www.w3.org/TR/1998/REC-xml-19980210
[XSLT]
"XSL Transformations (XSLT) Version 1.0", J. Clark. The 16 November 1999 Recommendation is http://www.w3.org/TR/1999/REC-xslt-19991116.