Techniques for User Agent Accessibility Guidelines 1.0

Abstract

This document provides techniques for satisfying the checkpoints defined in "Techniques for User Agent Accessibility Guidelines 1.0" [UAAG10]. These techniques cover the accessibility of user interfaces, content rendering, application programming interfaces (APIs), and languages such as the Hypertext Markup Language (HTML), Cascading Style Sheets (CSS) and the Synchronized Multimedia Integration Language (SMIL).

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 is the 13 January 2001 Working Draft of Techniques for User Agent Accessibility Guidelines 1.0, 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 User Agent Accessibility Guidelines Working Group (UAWG).

While Techniques for User Agent Accessibility Guidelines 1.0 strives to be a stable document (as a W3C Recommendation), the current document is expected to evolve as technologies change and content developers discover more effective techniques for designing accessible Web sites and pages.

Please send comments about this document, including suggestions for additional techniques, to the public mailing list w3c-wai-ua@w3.org; public archives are available.

This document is part of a series of accessibility documents published by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C). WAI Accessibility Guidelines are produced as part of the WAI Technical Activity. The goals of the User Agent Accessibility Guidelines Working Group are described in the charter.

A list of current W3C Recommendations and other technical documents can be found at the W3C Web site.

Related resources

"Techniques for User Agent Accessibility Guidelines 1.0" and the "User Agent Accessibility Guidelines 1.0" [UAAG10] are part of a series of accessibility guidelines published by the Web Accessibility Initiative (WAI). These documents explain the responsibilities of user agent developers in making the Web accessibility to users with disabilities. The series also includes the "Web Content Accessibility Guidelines 1.0" [WCAG10] (and techniques [WCAG10-TECHS]), which explain the responsibilities of authors, and the "Authoring Tool Accessibility Guidelines 1.0" [ATAG10] (and techniques [ATAG10-TECHS]), which explain the responsibilities of authoring tool developers.

1 Introduction

This document suggests some techniques for satisfying the requirements of the "User Agent Accessibility Guidelines 1.0" [UAAG10]. The techniques listed in this document are not required for conformance to the Guidelines. These techniques are not necessarily the only way of satisfying the checkpoint, nor are they a definitive set of requirements for satisfying a checkpoint.

2 The user agent accessibility guidelines

This section lists each checkpoint of "User Agent Accessibility Guidelines 1.0" [UAAG10] along with some possible techniques for satisfying it. Each checkpoint definition includes a link to the checkpoint definition in "User Agent Accessibility Guidelines 1.0". Each checkpoint definition is followed by a list of techniques, information about related resources, and references to the accessibility topics in section 3. The accessibility topics of section 3 apply to more than one checkpoint.

Note: Most of the techniques in this document are designed for mainstream (graphical) browsers and multimedia players. However, some of them also make sense for assistive technologies and other user agents. In particular, techniques about communication between user agents will benefit assistive technologies. Refer, for example, to the appendix on loading assistive technologies for access to the document object model.

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.

Note: This information about checkpoint priorities is included for convenience only. For detailed information about conformance to "User Agent Accessibility Guidelines 1.0" [UAAG10], please refer to that document.

Checkpoints for user interface accessibility:

1.1 Ensure that the user can operate the user agent fully through keyboard input alone, pointing device input alone, and voice input alone. [Priority 1] (Checkpoint 1.1)

Note: For example, ensure that through all three input modalities, the user can interact with active elements, select content, navigate viewports, configure the user agent, access documentation, install the user agent, etc. A user agent may claim conformance to User Agent Accessibility Guidelines 1.0 [UAAG10] without satisfying the pointing device and voice portions of this checkpoint. See the section on input modality labels in UAAG 1.0.

Techniques:

Since the subject of a claim may be one or more software components, one could, for example, claim conformance for the following software used together:

• a browser that doesn't support character input through the mouse
• an on-screen keyboard, operable through a pointing device, that communicates with the browser through a keyboard API.

Functionalities addressed by this checkpoint include the following:

• Select content and operate on it. For example, if the user can select rendered text with the mouse and make it the content of a new link by pushing a button, they must also be able to do so through the keyboard and other supported devices. Other operations include cut, copy, and paste.
• Set the focus. Ensure that software may be installed, uninstalled, and updated in a device-independent manner.
• Navigate content.
• Navigate links (see link techniques).
• Use the graphical user interface menus.
• Fill out forms.
• Access documentation.
• Configure the software.
• Install, uninstall, and update the user agent software.

Ensure that people with disabilities are involved in the design and testing of the software.

---

1.2 Ensure that the user can interact with all active elements through keyboard input alone, pointing device input alone, and voice input alone. [Priority 1] (Checkpoint 1.2)

Note: A user agent may claim conformance to User Agent Accessibility Guidelines 1.0 [UAAG10] without satisfying the pointing device and voice portions of this checkpoint. See the section on input modality labels in UAAG 1.0. This checkpoint is an important special case of checkpoint 1.1.

Techniques:

• For example, users without a pointing device (such as some users who are blind or have physical disabilities) must be able to activate form controls and links (including the links in a client-side image map).
• see checkpoint 1.1 and checkpoint 1.3.
• see image map techniques.
• In the "Document Object Model (DOM) Level 2 Events Specification" ([DOM2EVENTS]), all elements may have associated behaviors. Assistive technologies should be able to activate these elements through the DOM. For example, a DOM 'focusin' event may cause a JavaScript function to construct a pull-down menu. Allowing programmatic activation of this function will allow users to operate the menu through speech input (which benefits users of voice browsers in addition to assistive technology users). Note that, for a given element, the same event may trigger more than one event handler, and assistive technologies must be able to activate each of them. Descriptive information about handlers can allow assistive technologies to choose the most important functions for activation. This is possible in the Java Accessibility API [JAVAAPI], which provides an an AccessibleAction Java interface. This interface provides a list of actions and descriptions that enable selective activation. See also checkpoint 5.3.

---

1.3 Ensure that every message (e.g., prompt, alert, notification, etc.) that is a non-text element and is part of the user agent user interface has a text equivalent. [Priority 1] (Checkpoint 1.3)

Note: For example, if the user is alerted of an event by an audio cue, a visually-rendered text equivalent in the status bar would satisfy this checkpoint. Per checkpoint 5.4, a text equivalent for each such message must be available through a standard API. See also checkpoint 5.5.

Techniques:

• Render text messages graphically on the status bar of the user interface. Provide this information automatically and allow users to query the viewport for it (e.g., through a menu or keyboard binding).
• For graphical user interface elements such as proportional scroll bars, provide a text equivalent that conveys the proportion of the content viewed (e.g., as a percentage) and that may be rendered graphically, as synthesized speech, and as braille. For images that render gradually (coarsely to finely), it is not necessary to show percentages for each rendering pass.
• For beeps or flashes provide a text equivalent that can be rendered as braille, synthesized speech, or graphically-rendered text.
• For user interface components that convey important information using sound, also provide alternative, parallel graphical representation of the information for individuals who are deaf, hard of hearing, or operating the user agent in a noisy or silent environment where the use of sound is not practical. Provide braille renderings of text equivalents for deaf-blind users who cannot use audio or graphical cues and who rely on braille.
• Allow users to configure when to render status information so that assistive technologies may announce changes in status at appropriate times. For instance, allow the user to hide the status bar in order to hide a text rendering.
• Allow users to configure what status information they want rendered. Useful status information includes:
  • Document proportions (numbers of lines, pages, width, etc.);
  • Number of elements of a particular type (e.g., tables, forms, and headings);
  • Whether the viewport is at the beginning or end of the document;
  • Size of document in bytes;
  • The number of controls in a form and controls in a form control group (e.g., FIELDSET in HTML).

---

Checkpoints for content accessibility:

2.1 Make all content available through the user interface. [Priority 1] (Checkpoint 2.1)

Note: Users must have access to the entire document object through the user interface, including recognized equivalents, attributes, style sheets, etc. This checkpoint does not require that all content be available in every viewport. A document source view is an important part of a solution for providing access to content, but is not a sufficient solution on its own for all content. See guideline 5 for more information about programmatic access to content.

Techniques:

• Some users benefit from concurrent access to more than one equivalent. For instance, users with low vision may want to view images (even imperfectly) but require a text equivalent for the image; the text may be rendered with a large font or as speech. If a multimedia presentation has several captions (or subtitles) available, allow the user to choose from among them. Captions might differ in level of detail, reading levels, natural language, etc.
• When content changes dynamically (e.g., due to embedded scripts or content refresh), users must have access to the content before and after the change.
• Provide structured (not all at once) access to attribute values. For instance, allow the user to select an element and read values for all attributes set for that element. For many attributes, this type of inspection should be significantly more usable than a document source view.
• A document source view may be the most usable readily-achievable view for some content such as embedded fragments of style and scripting languages.
• In general, user agent developers should not rely on "source view" for conveying information to users, many of whom will not be familiar with markup languages and for whom navigation may be difficult. However, since some content may not be accessible to users otherwise, a source view may be useful as a "last resort" view.
• See the section on access to content.
• See the section on link techniques.
• See the section on table techniques.
• See the section on frame techniques.
• See the section on form techniques.
• Sections 10.4 ("Client Error 4xx") and 10.5 ("Server Error 5xx") of the HTTP/1.1 specification state that user agents should have the following behavior in case of these error conditions:

  Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included entity to the user.

• Make available information about abbreviation and acronym expansions. For instance, in HTML, look for abbreviations specified by the ABBR and ACRONYM elements. The expansion may be given with the "title" attribute (refer to the Web Content Accessibility Guidelines 1.0 [WCAG10], checkpoint 4.2). To provide expansion information, user agents may:
  • Allow the user to configure that the expansions be used in place of the abbreviations,
  • Provide a list of all abbreviations in the document, with their expansions (a generated glossary of sorts)
  • Generate a link from an abbreviation to its expansion.
  • Allow the user to query the expansion of a selected or input abbreviation.
  • If an acronym has no explicit expansion in one location, look for another occurrence in content with an explicit expansion. User agents may also look for possible expansions (e.g., in parentheses) in surrounding context, though that is a less reliable repair.

---

2.2 For a presentation that requires user input within a specified time interval controlled by the user agent, allow the user to configure the user agent to pause the presentation automatically and await user input before proceeding. [Priority 1] (Checkpoint 2.2)

Note: In this configuration, the user agent may have to pause the presentation more than once, depending on the number of times input is requested. In SMIL 1.0 [SMIL], for example, the "begin", "end", and "dur" attributes synchronize presentation components. This checkpoint does not apply when the user agent cannot recognize the time interval in the presentation format, or when the user agent cannot control the timing (e.g., because it is controlled by the server).

Techniques:

• Refer to section 4.2.4 of SMIL 1.0 [SMIL] for information about the SMIL time model.
• Some HTML user agents recognize time intervals specified through the META element, although this usage is not defined in HTML 4 [HTML4].
• Render time-dependent links as a static list that occupies the same screen real estate; authors may create such documents in SMIL 1.0 [SMIL]. Include temporal context in the list of links. For example, provide the time at which the link appeared along with a way to easily jump to that portion of the presentation.
• Provide easy-to-use controls (including both mouse and keyboard commands) to allow users to pause a presentation and advance and rewind by small or large time increments. Note: When a user must respond to a link by pausing the program and activating the link, the time dependent nature of the link does not change since the user must respond somehow in the predetermined time. The pause feature is only effective in conjunction with the ability to rewind to the link, or when the pause can be configured to stop the presentation automatically and require the user to respond before continuing, either by responding to the user input or by continuing with the flow of the document.
• Highlight the fact that there are active elements in a presentation and allow users to navigate to and activate them. For example, indicate the presence of active elements on the status bar and allow the user to navigate among them with the keyboard or mouse.
• For additional control, user agents may allow users to slow the presentation.

---

2.3 Provide easy access to each equivalent and each equivalency target through at least one of the following mechanisms: (1) allowing configuration to render the equivalent instead of the equivalency target; (2) allowing configuration to render the equivalent in addition to the equivalency target; (3) allowing the user to select the equivalency target and then inspect its equivalents; (4) providing a direct link to the equivalent in content, just before or after the equivalency target in document order. [Priority 1] (Checkpoint 2.3)

Note: For example, if an image in an HTML document has text equivalents, provide access to them (1) by replacing the image with the rendered equivalents, (2) by rendering the equivalents near the image, (3) by allowing the user to select the image and then inspect its equivalents, or (4) by allowing the user to follow readily available links to the equivalents.

Techniques:

• See the section on access to content.
• Allow users to choose more than one equivalent at a given time. For instance, multilingual audiences may wish to have captions in different natural languages on the screen at the same time. Users may wish to use both captions and auditory descriptions concurrently as well.
• Make apparent through the user agent user interface which audio tracks are meant to be played mutually exclusively.
• In the user interface, construct a list of all available tracks from short descriptions provided by the author (e.g., through the "title" attribute).
• Allow the user to configure different natural language preferences for different types of equivalents (e.g., captions and auditory descriptions). Users with disabilities may need to choose the language they are most familiar with in order to understand a presentation for which equivalent tracks are not all available in all desired languages. In addition, some users may prefer to hear the program audio in its original language while reading captions in another, fulfilling the function of subtitles or to improve foreign language comprehension. In classrooms, teachers may wish to configure the language of various multimedia elements to achieve specific educational goals.
• Consider system level natural language preferences as the user's default language preference. However, do not send HTTP Accept-Language request headers ([RFC2616], section 14.4) based on the operating system preferences. First, there may be a privacy problem as indicated in RFC 2616, section 15.1.4 "Privacy Issues Connected to Accept Headers". Also, the operating system defines one language, while the Accept-Language request header may include many languages in different priorities. Setting Accept-Language to be the operating system language may prevent a user from receiving content from a server that does not have a match for this particular language but does for other languages acceptable to the user.

This image shows how users select a natural language preference in the Real Player. This setting, in conjunction with language markup in the presentation, determines what content is rendered.

---

2.4 Allow the user to specify that text transcripts, collated text transcripts, captions, and auditory descriptions be rendered at the same time as the associated audio and visual tracks. [Priority 1] (Checkpoint 2.4)

Techniques:

• User agents that implement SMIL 1.0 ([SMIL]) should implement the "Accessibility Features of SMIL" [SMIL-ACCESS]. In particular, SMIL user agents should allow users to configure whether they want to view captions, and this user interface switch should be bound to the 'system-captions' test attribute. Users should be able to indicate a preference for receiving available auditory descriptions, but SMIL 1.0 does not include a mechanism equivalent to 'system-captions' for auditory descriptions. The next version of SMIL is expected to include a test attribute for auditory descriptions.

  Another SMIL 1.0 test attribute, 'system-overdub-or-captions', allows users to choose between subtitles and overdubs in multilingual presentations. User agents should not interpret a value of 'caption' for this test attribute as meaning that the user prefers accessibility captions; that is the purpose of the 'system-captions' test attribute. When subtitles and accessibility captions are both available, users who are deaf may prefer to view captions, as they generally contain information not in subtitles: information on music, sound effects, who is speaking, etc.

• User agents that play QuickTime movies should allow the user to turn on and off the different tracks embedded in the movie. Authors may use these alternative tracks to provide equivalents. The Apple QuickTime player currently provides this feature through the menu item "Enable Tracks."
• User agents that play Microsoft Windows Media Object presentations should provide support for Synchronized Accessible Media Interchange (SAMI [SAMI]), a protocol for creating and displaying captions) and should allow users to configure how captions are viewed. In addition, user agents which play Microsoft Windows Media Object presentations should enable people to turn on and off other equivalents, including auditory description and alternative visual tracks.
• For other formats, at a minimum, users must be able to turn on and off auditory descriptions and captions.

---

2.5 Respect author-specified synchronization cues during rendering. [Priority 1] (Checkpoint 2.5)

Techniques:

• Captions and auditory descriptions may not make sense unless rendered synchronously with related video or audio content. For instance, if someone with a hearing disability is watching a video presentation and reading associated captions, the captions must be synchronized with the audio so that the individual can use any residual hearing. For auditory descriptions, it is crucial that an audio track and an auditory description track be synchronized to avoid having them both play at once, which would reduce the clarity of the presentation.
• The idea of "sensible time-coordination" of components in the definition of synchronize centers on the idea of simultaneity of presentation, but also encompasses strategies for handling deviations from simultaneity resulting from a variety of causes. Consider how deviations might be handled for captions for a multimedia presentation such as a movie clip. Captions consist of a text equivalent of the audio track that is synchronized with the visual track. Captions are essential for individuals who require an alternative way of accessing the meaning of audio, such as individuals who are deaf. Typically, a segment of the captions appears visually near the video for several seconds while the person reads the text. As the visual track continues, a new segment of the captions is presented. However, a problem arises if the captions are longer than can fit in the display space. This can be particularly difficult if due to a visual disability, the font size has been enlarged, thus reducing the amount of rendered caption text that can be presented. The user agent must respond sensibly to such problems, for example by ensuring that the user has the opportunity to navigate (e.g., scroll down or page down) through the caption segment before proceeding with the visual presentation and presenting the next segment.

  Developers of user agents must determine how they will handle synchronization challenges, such as:

  1. Under what circumstances will the presentation automatically pause? Some circumstances where this might occur include:
     • the segment of rendered caption text is more than can fit on the visual display
     • the user wishes more time to read captions or the collated text transcript
     • the auditory description is of longer duration than the natural pause in the audio.
  2. Once the presentation has paused, then under what circumstances will it resume (e.g., only when the user signals it to resume, or based on a predefined pause length)?
  3. If the user agent allows the user to jump to a location in a presentation by clicking on a text equivalent (or some outline of it), then do all rendered equivalents jump at the same time? Will one be able to return to one's previous location (or undo the action)?

  Developers of user agents must anticipate many of the challenges that may arise in synchronization of diverse equivalents.

  The term "synchronization cues" in checkpoint 2.5 refers to pieces of information that may affect synchronization, such as the size and expected duration of equivalents and their segments, the type of element and how much those elements can be sped up or slowed down (both from technological and intelligibility standpoints), user preferences, etc.

---

2.6 Allow configuration to generate repair text when the user agent recognizes that the author has failed to provide a required equivalent. If the content missing an equivalent is included by URI reference, base the repair text on the URI reference and content type. Otherwise, base the repair text on element type information. [Priority 2] (Checkpoint 2.6)

Note: Some markup languages (such as HTML 4 [HTML4] and SMIL 1.0 [SMIL] require the author to provide text equivalents for some content. When they don't, the user agent is required by this document to generate repair text. See also checkpoint 2.7.

Techniques:

• When HTTP is used, HTTP headers provide information about the URI of the Web resource ("Content-Location") and its type ("Content-Type"). Refer to the HTTP/1.1 specification [RFC2616], sections 14.14 and 14.17, respectively. Refer to "Uniform Resource Identifiers (URI): Generic Syntax" ([RFC2396], section 4) for information about URI references, as well as the HTTP/1.1 specification [RFC2616], section 3.2.1.
• Text equivalents may come from markup, inside images (e.g., refer to "Describing and retrieving photos using RDF and HTTP" [PHOTO-RDF]), etc. User agents are expected to recognize equivalents by specification See techniques for missing equivalents.
• When configured to generate text, also inform the user (e.g., in the generated text itself) that this content was not provided intentionally by the author as a text equivalent.
• See content repair techniques

---

2.7 Allow configuration so that when the author has specified an empty text equivalent for non-text content, the user agent generates no repair text or generates repair text as required by checkpoint 2.6. [Priority 3] (Checkpoint 2.7)

Note: An empty text equivalent (e.g., alt="") is considered to be a valid text equivalent in some authoring scenarios. For instance, when some non-text content has no other function than pure decoration, or an image is part of a "mosaic" of several images and doesn't make sense out of the mosaic. Please refer to the Web Content Accessibility Guidelines 1.0 [WCAG10] for more information about text equivalents. See also checkpoint 2.6.

Techniques:

• User agents should render nothing in this case because the author may specify a null text equivalent for content that has no function in the page other than as decoration. In this case, the user agent should not render generic labels such as "[INLINE]" or "[GRAPHIC]".
• Allow the user to toggle the rendering of null text equivalents: between nothing and an indicator of a null equivalent (e.g., an icon with the text equivalent "EMPTY TEXT EQUIVALENT").

---

2.8 Allow the user to configure the user agent not to render content in unsupported natural languages. Indicate to the user in context that author-supplied content has not been rendered. [Priority 3] (Checkpoint 2.8)

Note: For example, use a text substitute or accessible graphical icon to indicate that content in a particular language has not been rendered. This checkpoint does not require the user agent to allow different configurations for different natural languages.

Techniques:

• Rendering content in an unsupported language (e.g., as "garbage" characters) may confuse all users. However, this checkpoint is designed primarily to benefit users who access content serially as it allows them to skip portions of content that would be unusable as rendered.
• CSS2's attribute selector may be used with the "lang" or "xml:lang" attributes to control rendering based on author-supplied natural language information.
• For instance, a user agent that doesn't support Korean (e.g., doesn't have the appropriate fonts or voice set) should allow configuration to announce the language change with the message "Korean text -- unable to read". The user should also be able to choose no alert of language changes. Rendering could involve speaking in the designated natural language in the case of a voice browser or screen reader. If the natural language is not supported, the language change alert could be spoken in the default language by a screen reader or voice browser.
• A user agent may not be able to render all characters in a document meaningfully, for instance, because the user agent lacks a suitable font, a character has a value that may not be expressed in the user agent's internal character encoding, etc. In this case, section 5.4 of HTML 4 [HTML4] recommends the following for undisplayable characters:
  1. Adopt a clearly visible (or audible), but unobtrusive mechanism to alert the user of missing resources.
  2. If missing characters are presented using their numeric representation, use the hexadecimal (not decimal) form since this is the form used in character set standards.
• Render characters with the appropriate directionality. Refer to the "dir" attribute and the BDO element in HTML 4 ([HTML4], sections 8.2 and 8.2.4 respectively). Refer also to the Unicode specification [UNICODE].
• See techniques for generated content, which may be used to insert text to indicate a language change.
• For information on language codes, refer to "Codes for the representation of names of languages" [ISO639].
• Refer to "Character Model for the World Wide Web" [CHARMOD]. It contains basic definitions and models, specifications to be used by other specifications or directly by implementations, and explanatory material. In particular, this document addresses early uniform normalization, string identity matching, string indexing, and conventions for URIs.
• Implement content negotiation so that users may specify language preferences. Or allow the user to choose a Web resource when several are available in different languages.
• There may be cases when a conforming user agent supports a natural language but a speech synthesizer does not, or vice versa.
• See techniques for synthesized speech and checkpoint 5.4.
• See content repair techniques

---

In addition to the techniques below, refer also to the section on user control of style.

Checkpoints for content accessibility:

3.1 Allow the user to configure the user agent not to render background images. In this configuration, provide an option to alert the user when a background image is available (but has not been rendered). [Priority 1] (Checkpoint 3.1)

Note: This checkpoint only requires control of background images for "two-layered renderings", i.e., one rendered background image with all other content rendered "above it". When background images are not rendered, user agents should render a solid background color (see checkpoint 4.3). In this configuration, the user agent is not required to retrieve background images from the Web.

Techniques:

• Since background images may make it difficult or impossible to read superimposed text, allow the user to turn off embedded or background images through the user agent user interface. Note that any equivalents for those images must still be available.
• In CSS, background images may be turned on/off with the 'background' and 'background-image' properties ([CSS2], section 14.2.1).
• This checkpoint does not address issues of multi-layered renderings and does not require the user agent to change background rendering for multi-layer renderings (refer, for example, to the 'z-index' property in Cascading Style Sheets, level 2 ([CSS2], section 9.9.1).

---

3.2 Allow the user to configure the user agent not to render audio, video, or animated images except on explicit request from the user. In this configuration, provide an option to render a placeholder in context for each unrendered source of audio, video, or animated image. When placeholders are rendered, allow the user to activate each placeholder individually and replace it with the original author-supplied content. [Priority 1] (Checkpoint 3.2)

Note: This checkpoint requires configuration for content rendered without any user interaction (including content rendered on load or as the result of a script) as well as content rendered as the result of user interaction that is not an explicit request (e.g., when the user activates a link). Activation of a placeholder is considered an explicit user request to render the original content. When configured not to render content except on explicit user request, the user agent is not required to retrieve the audio, video, or animated image from the Web until requested by the user. See also checkpoint 4.5, checkpoint 4.9 and checkpoint 4.10.

Techniques:

• User agent may satisfy this checkpoint by treating content as invisible or silent (e.g., by implementing the 'visibility' property defined in section 11.2 of CSS 2 [CSS2]). However, this solution means that the content is processed, though not rendered, and processing may cause undesirable side effects such as triggering events. Or, processing may interfere with the processing of other content (e.g., silent audio may interfere with other sources of sound such as the output of a speech synthesizer). This technique should be deployed with caution.

---

3.3 Allow the user to configure the user agent to render animated or blinking text as motionless, unblinking text. [Priority 1] (Checkpoint 3.3)

Note: This checkpoint does not apply for blinking and animation effects that are caused by mechanisms that the user agent cannot recognize.

Techniques:

• Allow the user to turn off animated or blinking text through the user agent user interface (e.g., by pressing the Escape key to stop animations). Render static text in place of blinking text.
• Some sources of blinking and moving text are:
  • The BLINK element in HTML. Note: The BLINK element is not defined by a W3C specification.
  • The MARQUEE element in HTML. Note: The MARQUEE element is not defined by a W3C specification.
  • The 'blink' value of the 'text-decoration' property in CSS ([CSS2], section 16.3.1).
  • In JavaScript, to control the start and speed of scrolling for a MARQUEE element:
    • document.all.myBanner.start();
    • document.all.myBanner.scrollDelay = 100

---

3.4 Allow the user to configure the user agent to render blinking images as motionless, unblinking images. [Priority 1] (Checkpoint 3.4)

Techniques:

• Use, for example, the first frame of the blinking image as the motionless, unblinking substitute.
• Allow the user to turn off the blinking image through the user agent user interface (e.g., by pressing the Escape key to stop animations).

---

3.5 Allow the user to configure the user agent not to execute any scripts or applets. In this configuration, provide an option to alert the user when scripts or applets are available (but have not been executed). [Priority 1] (Checkpoint 3.5)

Techniques:

• Control of scripts is particularly important when they can 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. Peak sensitivity to flickering or flashing occurs at 20 Hertz.
• The alert that scripts are available but not executed is important, for instance, for helping users understand why some poorly authored pages without script alternatives produce no content when scripts are turned off.
• This checkpoint includes scripts that run on load and when other events occur (e.g., user interface events).
• See the section on script techniques

---

3.6 Allow configuration so that an author-specified "client-side redirect" (i.e., one initiated by the user agent, not the server) does not change content except on explicit user request. Allow the user to access the new content on demand (e.g., by following a link or confirming a prompt). The user agent is not required to provide these functionalities for client-side redirects that occur instantaneously (i.e., when there is no delay before the new content is retrieved). [Priority 2] (Checkpoint 3.6)

Techniques:

• For Web content authors: refer to the HTTP/1.1 specification [RFC2616] for information about using server-side redirect mechanisms (instead of client-side redirects).
• The user agent may allow configuration to allow access on demand to new content even when the client-side redirect has been specified by the author to be instantaneous.

---

3.7 Allow configuration so that author-specified content refreshes do not change content except on explicit user request. Allow the user to request the new content on demand (e.g., by following a link or confirming a prompt). Alert the user, according to the schedule specified by the author, whenever fresh content is available (to be obtained on explicit user request). [Priority 2] (Checkpoint 3.7)

Techniques:

• Alert the user of pages that refresh automatically and allow them to specify a refresh rate through the user agent user interface.
• Allow the user to slow content refresh to once per 10 minutes.
• Some HTML authors create a refresh effect by using a META element with http-equiv="refresh" and the refresh rate specified in seconds by the "content" attribute.

---

3.8 Allow the user to configure the user agent not to render images. In this configuration, provide an option to render a placeholder in context for each unrendered image. When placeholders are rendered, allow the user to activate each placeholder individually and replace it with the original author-supplied content. [Priority 2] (Checkpoint 3.8)

Techniques:

• Provide a simple command that allows users through the user agent user interface to turn on/off the rendering of images on a page. When images are turned off, render any associated equivalents.
• See techniques for checkpoint 3.1.

---

In addition to the techniques below, refer also to the section on user control of style.

Checkpoints for visually rendered text (content accessibility):

4.1 Allow the user to configure globally and control the reference size of rendered text, with an option to override reference sizes specified by the author or user agent defaults. Allow the user to choose from among the full range of font sizes supported by the system. [Priority 1] (Checkpoint 4.1)

Note: The reference size of rendered text corresponds to the default value of the CSS2 'font-size' property, which is 'medium' (refer to CSS2 [CSS2], section 15.2.4). The default reference size of rendered text may vary among user agents. User agents may offer different mechanisms to allow the user to control the size of rendered text, for example by allowing the user to change the font size or by allowing the user to zoom or magnify content (refer, for example to the Scalable Vector Graphics specification [SVG]).

Techniques:

• The choice of optimal techniques depends in part on which markup language is being used. For instance, HTML user agents may allow the user to change the font size of a particular piece of text (e.g., by using CSS user style sheets) independent of other content (e.g., images). Since the user agent can reflow the text after resizing the font, the rendered text will become more legible without, for example, distorting bitmap images. On the other hand, some languages, such as SVG, do not allow text reflow, which means that changes to font size may cause rendered text to overlap with other content, reducing accessibility. SVG is designed to scale, making a zoom functionality the more natural technique for SVG user agents satisfying this checkpoint.
• Inherit text size information from user preferences specified for the operating system.
• Allow the user to configure the text size on an element level (i.e., more precisely than globally). User style sheets allow such detailed configurations.
• Allow the user to configure the text size differently for different scripts (i.e., writing systems).
• Use operating system magnification features.
• Implement the 'font-size' property in CSS ([CSS2], section 15.2.4).
• When scaling text, maintain size relationships among text of different sizes.
• Allow users to configure link text to be rendered so that users with physical disabilities using a mouse may easily activate links. This may be done through style sheets, for example.

---

4.2 Allow the user to configure globally the font family of all rendered text, with an option to override font families specified by the author or user agent defaults. Allow the user to choose from among the full range of font families supported by the system. [Priority 1] (Checkpoint 4.2)

Note: For example, allow the user to specify that all text must be rendered in a particular sans-serif font family. For text that cannot be rendered properly using the user's selected font family, the user agent may select an alternative font family.

Techniques:

• Inherit font family information from user preferences specified for the operating system.
• Implement the 'font-family' property in CSS ([CSS2], section 15.2.2).
• Allow the user to override author-specified font families with differing levels of detail. For instance, use font A in place of any sans-serif font and font B in place of any serif font.
• Allow the user to configure font families on an element level (i.e., more precisely than globally). User style sheets allow such detailed configurations.

---

4.3 Allow the user to configure globally the foreground and background color of all rendered text, with an option to override foreground and background colors specified by the author or user agent defaults. Allow the user to choose from among the full range of colors supported by the system. [Priority 1] (Checkpoint 4.3)

Note: User configuration of foreground and background colors may result in the inability to distinguish ordinary text from selected text, focused text, etc. See checkpoint 8.2 for more information about highlight styles.

Techniques:

• Inherit foreground and background color information from user preferences specified for the operating system.
• Implement the 'color' and 'border-color' properties in CSS 2 ([CSS2], sections 14.1 and 8.5.2, respectively).
• Implement the 'background-color' property (and other background properties) in CSS 2 ([CSS2], section 14.2.1).
• Allow the user to specify minimal contrast between foreground and background colors, adjusting colors dynamically to meet those requirements.

---

Checkpoints for multimedia presentations and other presentations that change continuously over time (content accessibility):

4.4 Allow the user to slow the presentation rate of audio, video and animations. For a visual track, provide at least one setting between 40% and 60% of the original speed. For a prerecorded audio track including audio-only presentations, provide at least one setting between 75% and 80% of the original speed. 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. The user agent is not required to satisfy this checkpoint for audio, video and animations whose recognized role is to create a purely stylistic effect. [Priority 1] (Checkpoint 4.4)

Note: Purely stylistic effects include background sounds, decorative animated images, and effects caused by style sheets. The style exception of this checkpoint is based on the assumption that authors have satisfied the requirements of the "Web Content Accessibility Guidelines 1.0" [WCAG10] not to convey information through style alone (e.g., through color alone or style sheets alone). See also checkpoint 4.7.

See also checkpoint 2.5.

Techniques:

• Allowing the user to slow the presentation of video, animations, and audio will benefit individuals with specific learning disabilities, cognitive disabilities, or individuals with newly acquired sensory limitations (such as a person who is newly blind and learning to use a screen reader). The same feature will benefit individuals who have beginning familiarity with a natural language.
• Allowing the user to speed up audio is also useful. For example, some users who access content serially benefit from the ability to speed up audio.
• When changing the rate of audio, avoid pitch distortion.
• Some formats do not allow changes in playback rate.
• HTML 4 [HTML4], background animations may be specified with the deprecated background attribute.
• Authors sometimes specify background sounds with the "bgsound" attribute. Note: This attribute is not part of HTML 4 [HTML4].

---

4.5 Allow the user to stop, pause, resume, fast advance, and fast reverse audio, video, and animations that last three or more seconds at their default playback rate. The user agent is not required to satisfy this checkpoint for audio, video and animations whose recognized role is to create a purely stylistic effect. [Priority 1] (Checkpoint 4.5)

Note: See checkpoint 4.4 for more information about the exception for purely stylistic effects. This checkpoint applies to content that is rendered automatically or on request from the user. Enable control of each independent source recognized as distinct. Respect synchronization cues per checkpoint 2.5. See also checkpoint 3.2.

Techniques:

• Allow the user to advance or rewind the presentation in increments. This is particularly valuable to users with physical disabilities who may not have fine control over advance and rewind functionalities. Allow users to configure the size of the increments.
• Some content lends itself to different forward and reverse functionalities. For instance, compact disk players often let listeners fast forward and reverse, but also skip to the next or previous song.
• The user agent should display time codes or represent otherwise position in content to orient the user.
• If buttons are used to control advance and rewind, make the advance/rewind distances proportional to the time the user activates the button. After a certain delay, accelerate the advance/rewind.
• Apply techniques for changing audio speed without introducing distortion.
• Note that Home Page Reader [HPR] lets users insert bookmarks in presentations.

---

4.6 For graphical viewports, allow the user to position text transcripts, collated text transcripts, and captions in the viewport. Allow the user to choose from among the same range of positions available to the author (e.g., the range of positions allowed by the markup or style language). [Priority 1] (Checkpoint 4.6)

Techniques:

• Some users need to be able to position captions, etc. so that they do not obscure other content or are not obscured by other content. Other users (e.g., users with screen magnifiers or who have other visual disabilities) require pieces of content to be in a particular relation to one another, even if this means that some content will obscure other content.
• User agents should implement the positioning features of the employed markup or style sheet language. Even when a markup language does not explicitly allow positioning, when a user agent can recognize distinct text transcripts, collated text transcripts, or captions, the user agent should allow the user to reposition them. User agents are not required to allow repositioning when the captions, etc. cannot be separated from other media (e.g., the captions are part of the video track).
• Implement the CSS 2 'position' property ([CSS2], section 9.3.1).
• Allow the user to choose whether captions appear at the bottom or top of the video area or in other positions. Currently authors may place captions overlying the video or in a separate box. Captions prevent users from being able to view other information in the video or on other parts of the screen, making it necessary to move the captions in order to view all content at once. In addition, some users will find captions easier to read if they can place them in a location best suited to their reading style.
• Allow users to configure a general preference for caption position and to be able to fine tune specific cases. For example, the user may want the captions to be in front of and below the rest of the presentation.
• Allow the user to drag and drop the captions to a place on the screen. To ensure device-independence, allow the user to enter the screen coordinates of one corner of the caption.
• Allow the user to position all parts of a presentation rather than trying to identify captions specifically (i.e., solving the problem generally may be easier than for captions alone).
• Do not require users to edit the source code of the presentation to achieve the desired effect.

---

4.7 Allow the user to slow the presentation rate of audio, video and animations not covered by checkpoint 4.4. The same speed percentage requirements of checkpoint 4.4 apply. [Priority 2] (Checkpoint 4.7)

Note: User agents automatically satisfy this checkpoint if they satisfy checkpoint 4.4 for every audio, video, and animation.

Techniques:

See the techniques for checkpoint 4.4.

---

4.8 Allow the user to stop, pause, resume, fast advance, and fast reverse audio, video, and animations not covered by checkpoint 4.5. [Priority 2] (Checkpoint 4.8)

Note: User agents automatically satisfy this checkpoint if they satisfy checkpoint 4.5 for every audio, video, and animation.

Techniques:

See the techniques for checkpoint 4.5.

---

Checkpoints for audio volume control (content accessibility):

4.9 Allow the user to configure globally and control the volume of all audio, with an option to override audio volumes specified by the author or user agent defaults. The user must be able to choose zero volume (i.e., silent). [Priority 1] (Checkpoint 4.9)

Note: User agents should allow configuration and control of volume through available system-level controls.

Techniques:

• Use audio control mechanisms provided by the operating system. Control of volume mix is particularly important, and the user agent should provide easy access to those mechanisms provided by the operating system.
• Implement the CSS 2 'volume' property ([CSS2], section 19.2).
• Allow the user to configure a volume level at the operating system level.
• Implement the 'display', 'play-during', and 'speak' properties in CSS 2 ([CSS2], sections 9.2.5, 19.6, and 19.5, respectively).
• Authors sometimes specify background sounds with the "bgsound" attribute. Note: This attribute is not part of HTML 4 [HTML4].

---

4.10 Allow the user to control independently the volumes of distinct audio sources synchronized to play simultaneously. [Priority 1] (Checkpoint 4.10)

Note: Sounds that play at different times are distinguishable and therefore independent control of their volumes is not part of this checkpoint (volume control per checkpoint 4.9 suffices). The user agent may satisfy this checkpoint by allowing the user to control independently the volumes of all distinct audio sources. The user control required by this checkpoint includes the ability to override author-specified volumes for the relevant sources of audio. See also checkpoint 4.12.

Techniques:

• For each source of audio recognized as distinct, allow the user to control the volume using the same user interface used to satisfy the requirements of checkpoint 4.5.

---

Checkpoints for synthesized speech (content accessibility):

See also techniques for synthesized speech.

4.11 Allow the user to configure and control synthesized speech playback rate according to the full range offered by the speech synthesizer. [Priority 1] (Checkpoint 4.11)

Note: The range of playback rates offered by the speech synthesizer may depend on the natural language.

Techniques:

• For example, many speech synthesizers offer a range for English speech of 120 - 500 words per minute or more. The user should be able to increase or decrease the playback rate in convenient increments (e.g., in large steps, then in small steps for finer control).
• Content may include commands that are interpreted by a speech engine to change the speech rate (or control other speech parameters). This checkpoint does not require the user agent to allow the user to override author-specified speech rate changes (e.g., by transforming or otherwise stripping out these commands before passing on the content to the speech engine). Speech engines themselves may allow user override of author-specified speech rate changes. For these such speech engines, the user agent should ensure access to this feature as part of satisfying this checkpoint.
• User agents may allow different playback rate configurations for different natural languages. For example, this may be implemented with CSS2 style sheets using the :lang pseudo-class ([CSS2], section 5.11.4).
• Use synthesized speech mechanisms provided by the operating system.
• Implement the CSS 2 'speech-rate' property ([CSS2], section 19.8).

---

4.12 Allow the user to control synthesized speech volume independent of other sources of audio. [Priority 1] (Checkpoint 4.12)

Note: The user control required by this checkpoint includes the ability to override author-specified speech volume. See also checkpoint 4.10.

Techniques:

• The user agent should allow the user to make synthesized speech louder and softer than other audio sources.
• Use synthesized speech mechanisms provided by the operating system.
• Implement the CSS 2 'volume' property ([CSS2], section 19.2).

---

4.13 Allow the user to configure synthesized voice gender, pitch, pitch range, stress, richness, speech dictionary, and handling of spelling, punctuation, and number processing according to the full range of values offered by the speech synthesizer. [Priority 2] (Checkpoint 4.13)

Note: Many speech synthesizers allow users to choose from among preset options that control different voice parameters (gender, pitch range, stress, richness, etc.) as a group. When using these synthesizers, allow the user to choose from among the full range of preset options (e.g., "adult male voice", "female child voice", "robot voice", etc.). Ranges of values for these characteristics may vary among speech synthesizers. For information about these synthesized speech characteristics, please refer to descriptions in section 19.8 of Cascading Style Sheets Level 2 [CSS2].

Techniques:

• Use synthesized speech mechanisms provided by the operating system.
• Implement the voice characteristic properties of CSS 2: 'voice-family', 'pitch', 'pitch-range', 'stress', 'richness', ([CSS2], sections 19.8 and 19.9).
• One example of a speech API is Microsoft's Speech Application Programming Interface [SAPI].

---

Checkpoints for user interface accessibility:

4.14 For user agents that support style sheets, allow the user to choose from (and apply) available author and user style sheets or to ignore them. [Priority 1] (Checkpoint 4.14)

Note: By definition, the user agent's default style sheet is always present, but may be overridden by author or user styles.

Techniques:

• For HTML [HTML4], make available "class" and "id" information so that users can override styles.
• Implement user style sheets.
• Implement the "!important" semantics of CSS 2 ([CSS2], section 6.4.2).
• For information about how alternative style sheets are specified in HTML 4 [HTML4], please refer to section 14.3.1.
• For information about how alternative style sheets are specified in XML 1.0 [XML], please refer to "Associating Style Sheets with XML documents Version 1.0" [XMLSTYLE].

---

4.15 Allow the user to configure whether the current focus moves automatically to a viewport that opens without an explicit request from the user. [Priority 2] (Checkpoint 4.15)

Techniques:

• If the focus automatically changes to a new viewport, this may disorient users with cognitive disabilities or who are blind and it may be difficult to navigate back to the previous point of regard.
• Allow the user to configure how current focus changes when a new viewport opens. For instance, the user might choose between these two options:
  1. Do not change the focus when a viewport opens, but alert the user (e.g., with a beep, flash, and text message on the status bar). Allow the user to navigate directly to the new window upon demand.
  2. Change the focus when a window opens and use a subtle alert (e.g., a beep, flash, and text message on the status bar) to indicate that the focus has changed.
• If a new viewport or prompt appears but focus does not move to it, alert assistive technologies (per checkpoint 5.5) so that they may discreetly inform the user.
• When a viewport is duplicated, the focus in the new viewport should initially be the same as the focus in the original viewport. Duplicate viewports allow users to navigate content (e.g., in search of some information) in one viewport while allowing the user to return with little effort to the point of regard in the duplicate viewport. There are other techniques for accomplishing this (e.g., "registers" in emacs).
• In JavaScript, the focus may be changed with myWindow.focus();
• For user agents that implement CSS 2 [CSS2], the following rule will generate a message to the user at the beginning of link text for links that are meant to open new windows when followed:

     A[target=_blank]:before{content:"Open new window"}
  

---

4.16 Ensure that when a viewport's selection or content focus changes, it is in the viewport after the change. [Priority 2] (Checkpoint 4.16)

Note: For example, if users navigating links move to a portion of the document outside a graphical viewport, the viewport should scroll to include the new location of the focus. Or, for users of audio viewports, allow configuration to render the selection or focus immediately after the change.

Techniques:

• There are times when the content focus changes (e.g., link navigation) and the viewport must be moved to track it. There are other times when the viewport changes position (e.g., scrolling) and the content focus is moved to follow it. In both cases, the focus (or selection) is in the viewport after the change.
• If a search causes the selection or focus to change, ensure that the found content is not hidden by the search prompt.
• When the content focus changes, register the newly focused element in the navigation sequence; sequential navigation should start from there.
• Unless viewports have been coordinated explicitly, changes to selection or focus in one viewport should not affect the selection or focus in another viewport.
• The persistence of the selection or focus in the viewport will vary according to the type of viewport. For any viewport with persistent rendering (e.g., a two-dimensional graphical or tactile viewport), the focus or selection should remain in the viewport after the change until the user changes the viewport. For any viewport without persistent rendering (e.g., and audio viewport), once the focus or selection has been rendered, it will no longer be "in" the viewport. In a pure audio environment, the whole persistent context is in the mind of the user. In a graphical viewport, there is a large shared buffer of dialog information in the display. In audio, there is no such sensible patch of interaction that is maintained by the computer and accessed ad lib by the user. The audio rendering of content requires the elapse of time and time becomes a scarce resource and the flowing of content through the display has to be managed more carefully, which means that in accessing content that was edited at the source for use with a graphical user interface, it generally has to be managed actively.
• If the rendered selection or focus does not fit entirely within the limits of a graphical viewport:
  1. if the region actually displayed prior to the change was within the selection or focus, do not move the viewport.
  2. otherwise, if the region actually displayed prior to the change was not within the newly selected or focused content, move to display at least the initial fragment of such content.

---

4.17 For graphical user interfaces, allow the user to configure the user agent so that the viewport with the current focus remains "on top" of all other viewports with which it overlaps. [Priority 2] (Checkpoint 4.17)

Techniques:

• The alert is important to ensure that the user realizes a new viewport has opened, since it may be hidden by the viewport configured to remain on top.

---

4.18 Allow the user to configure the user agent to only open viewports on explicit user request. In this configuration, instead of opening a viewport automatically, alert the user and allow the user to open it on demand (e.g., by following a link or confirming a prompt). Allow the user to close viewports. If a viewport (e.g., a frame set) contains other viewports, these requirements only apply to the outermost container viewport. [Priority 2] (Checkpoint 4.18)

Note: User creation of a new viewport (e.g., empty or with a new resource loaded) through the user agent's user interface constitutes an explicit user request. See also checkpoint 4.15 (for control over changes of focus when a viewport opens) and checkpoint 5.5.

Techniques:

• Navigation of multiple open viewports may be difficult for some users who navigate viewports serially (e.g., users with visual or physical disabilities) and for some users with cognitive disabilities (who may be disoriented).
• For HTML [HTML4], allow the user to control the process of opening a document in a new "target" frame or a viewport created by a script. For example, for target="_blank", open the window according to the user's preference.
• For SMIL [SMIL], allow the user to control viewports created with the "new" value of the "show" attribute.
• In JavaScript, windows may be opened with:
  • myWindow.open("example.com", "My New Window");
  • myWindow.showHelp(URI);

---

4.19 Allow configuration so the user is prompted to confirm any viewport that closes without explicit user request. [Priority 3] (Checkpoint 4.19)

Techniques:

• In JavaScript, windows may be closed with myWindow.close();

---

Checkpoints for communication with other software:

5.1 Provide programmatic read access to HTML and XML content by conforming to the following modules of the W3C Document Object Model DOM Level 2 Core Specification [DOM2CORE] and exporting the interfaces they define: (1) the Core module for HTML; (2) the Core and XML modules for XML. [Priority 1] (Checkpoint 5.1)

Note: Please refer to the "Document Object Model (DOM) Level 2 Core Specification" [DOM2CORE] for information about HTML and XML versions covered.

Techniques:

• Note that the W3C DOM is designed to be used on a server as well as a client and does not address some user interface-specific information.
• See the appendix on loading assistive technologies for DOM access.
• For information about rapid access to Internet Explorer's [IE-WIN] DOM through COM, refer to [BHO].
• Refer to the DirectDOM Java implementation of the DOM [DIRECTDOM].

---

5.2 If the user can modify HTML and XML content through the user interface, provide the same functionality programmatically by conforming to the following modules of the W3C Document Object Model DOM Level 2 Core Specification [DOM2CORE] and exporting the interfaces they define: (1) the Core module for HTML; (2) the Core and XML modules for XML. [Priority 1] (Checkpoint 5.2)

Note: For example, if the user interface allows users to complete HTML forms, this must also be possible through the required DOM APIs. Please refer to the "Document Object Model (DOM) Level 2 Core Specification" [DOM2CORE] for information about HTML and XML versions covered.

Techniques:

Allowing assistive technologies write access through the DOM allows them to:

• modify the attribute list of a document and thus add information into the document object that will not be rendered by the user agent.
• add entire nodes to the document that are specific to the assistive technologies and that may not be rendered by a user agent unaware of their function.

The ability to write to the DOM can improve performance for the assistive technology. For example, if an assistive technology has already traversed a portion of the document object and knows that a section (e.g., a style element) could not be rendered, it can mark this section "to be skipped".

Another benefit is to add information necessary for audio rendering but that would not be stored directly in the DOM during parsing. Consider an ordered list. The Internet Explorer 5.5 [IE-WIN] document object model for HTML tells you that list elements are part of an ordered list but does not tell you each list element's number. The assistive technology can add the list element number to each list entry in its attribute list, for audio rendering. Furthermore, the assistive technology component that added the numeric information can mark that section as having been traversed and updated to prevent having to recompute and store the numeric information on the next pass through by the user.

See also techniques for checkpoint 5.1.

---

5.3 For markup languages other than HTML and XML, provide programmatic access to content using standard APIs (e.g., platform-independent APIs and standard APIs for the operating system). [Priority 1] (Checkpoint 5.3)

Note: This checkpoint addresses content not covered by checkpoints checkpoint 5.1 and checkpoint 5.2.

Techniques:

• See techniques for checkpoint 5.4.
• Some examples of markup languages covered by this checkpoint include SGML applications other than HTML and RTF, and TeX.
• Some public APIs that enable access include:
  • Microsoft Active Accessibility ([MSAA]) in Windows 95/98/NT versions.
  • Sun Microsystems Java Accessibility API ([JAVAAPI]) in Java JDK. If the user agent supports Java applets and provides a Java Virtual Machine to run them, the user agent should support the proper loading and operation of a Java native assistive technology. This assistive technology can provide access to the applet as defined by Java accessibility standards.

---

5.4 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 defined for a specific operating system; and conventions for programming languages, plug-ins, virtual machine environments, etc.) [Priority 1] (Checkpoint 5.4)

Note: For example, provide access to information about the user agent's current input configuration so that assistive technologies can trigger functionalities through keyboard events, mouse events, etc.

Techniques:

• Use standard operating system and programming language APIs that support accessibility by providing a bridge between the standard user interface supported by the operating system and alternative user interfaces developed by assistive technologies. User agents that implement these APIs are generally more compatible with assistive technologies and provide accessibility at no extra cost. Some public APIs that enable access include:
  • Microsoft Active Accessibility ([MSAA]) in Windows 95/98/NT versions.
  • Sun Microsystems Java Accessibility API ([JAVAAPI]) in Java JDK. If the user agent supports Java applets and provides a Java Virtual Machine to run them, the user agent should support the proper loading and operation of a Java native assistive technology. This assistive technology can provide access to the applet as defined by Java accessibility standards.
• Use standard user interface controls. Third-party assistive technology developers are more likely able to access standard controls than custom controls. If you must use custom controls, review them for accessibility and compatibility with third-party assistive technology. Ensure that they provide accessibility information through an API as is done for the standard controls.
• Make use of operating system level features. See the appendix of accessibility features for some common operating systems.
• Provide information about the selection and focus.
• Inherit operating system settings related to accessibility (e.g., for fonts, colors, natural language preferences, input configurations, etc.).
• Write output to and take input from standard system APIs rather than directly from hardware controls. This will enable the I/O to be redirected from or to assistive technology devices – for example, screen readers and braille displays often redirect output (or copy it) to a serial port, while many devices provide character input, or mimic mouse functionality. The use of generic APIs makes this feasible in a way that allows for interoperability of the assistive technology with a range of applications.
• For information about rapid access to Internet Explorer's [IE-WIN] DOM through COM, refer to Browser He