#Techniques for UAAG 1.0 Postscript format Techniques for UAAG 1.0 PDF format Techniques for UAAG 1.0 plain text format Techniques for UAAG 1.0 zip archive [contents] _________________________________________________________________ W3C Techniques for User Agent Accessibility Guidelines 1.0 W3C Working Draft 1 September 2000 This version: http://www.w3.org/WAI/UA/WD-UAAG10-TECHS-20000901 (plain text, gzip PostScript, gzip PDF, gzip tar file of HTML, zip archive of HTML) Latest version: http://www.w3.org/WAI/UA/UAAG10-TECHS Previous version: http://www.w3.org/WAI/UA/WD-UAAG10-TECHS-20000818 Editors: Ian Jacobs, W3C Jon Gunderson, University of Illinois at Urbana-Champaign Authors and Contributors: Refer to acknowledgements. Copyright ©1999 - 2000 W3C^® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. _________________________________________________________________ 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 1 September 2000 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 WAI User Agent (UA) Working Group. 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 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 the W3C Web site. Table of contents * Abstract * Status of this document * 1 Introduction * 2 User agent accessibility guidelines + 1. Support input and output device-independence. + 2. Ensure user access to all content. + 3. Allow the user to configure the user agent not to render some content that may reduce accessibility. + 4. Ensure user control of styles. + 5. Observe system conventions and standard interfaces. + 6. Implement accessible specifications. + 7. Provide navigation mechanisms. + 8. Orient the user. + 9. Notify the user of content and viewport changes. + 10. Allow configuration and customization. + 11. Provide accessible product documentation and help. * 3 Accessibility topics + 3.1 Access to content + 3.2 User control of style + 3.3 Link techniques + 3.4 List techniques + 3.5 Table techniques + 3.6 Image map techniques + 3.7 Frame techniques + 3.8 Form techniques + 3.9 Generated content techniques + 3.10 Script and applet techniques + 3.11 Input configuration techniques + 3.12 Speech techniques * 4 Appendix: Accessibility features of some operating systems * 5 Appendix: Loading assistive technologies for access to the document object model * 6 Glossary * 7 References * 8 Resources + 8.1 Operating system and programming guidelines + 8.2 User agents and other tools + 8.3 Accessibility resources + 8.4 Standards resources * 9 Acknowledgments Note: This document supports direct keyboard navigation to the table of contents via the "c" character. Users may have to use additional keyboard strokes depending on their operating environment. Not all user agents support direct keyboard access. "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] and evaluation and repair techniques [AERT]), 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 provides some suggestions for satisfying the requirements of the "Techniques for 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 necessarily a definitive set of requirements for satisfying a checkpoint. 2 User agent accessibility guidelines This section lists each checkpoint of Techniques for User Agent Accessibility Guidelines 1.0 [UAAG10] along with some possible techniques for satisfying it. Each checkpoint also links to more general accessibility topics where appropriate. Section 2 of this document reproduces the guidelines and checkpoints of the Techniques for User Agent Accessibility Guidelines 1.0 [UAAG10]. Each checkpoint definition includes a link to the checkpoint definition in Techniques for User Agent Accessibility Guidelines 1.0 [UAAG10]. Each checkpoint definition is followed by a list of techniques, information about related resources, and references to the accessibility topics in section 3. These accessibility topics may apply to more than one checkpoint and so have been split off into a stand-alone section. Note: Most of the techniques in this document are designed for graphical desktop 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. Guideline 1. Support input and output device-independence. Checkpoints for communication with other software: 1.1 Ensure that every functionality available through the user interface is also available through every input API implemented by the user agent. This checkpoint does not require developers to reimplement the input methods associated with the keyboard, pointing device, voice, and other input APIs. [Priority 1] (Checkpoint 1.1) Note: This checkpoint does not require developers to implement all operating system input APIs, only to make the software accessible through those they do implement. Developers are not required to reimplement input methods of APIs, e.g., text input through a mouse API or pointer motion through a keyboard API. Techniques: Ensure that the user can do the following with all supported input devices: + Select content and operate on it. For example, if the user can select text with the mouse and make that text 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 (refer to 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 Use the standard input and output APIs of the operating system. Do not bypass the standard output APIs when rendering information. [Priority 1] (Checkpoint 1.2) Note: For example, do not bypass (for reasons of speed, efficiency, etc.) standard APIs to manipulate the memory associated with rendered content, since assistive technologies monitor rendering through the APIs. When available, developers should use APIs at a higher level of abstraction than the standard device APIs for the operating system. If these higher level APIs do not use the standard device APIs properly, developers should also use the standard device APIs. Techniques: + Operating system and application frameworks provide standard mechanisms for communication with input devices. In the case of Windows, OS/2, the X Windows System, and Mac OS, the window manager provides Graphical User Interface (GUI) applications with this information through the messaging queue. In the case of non-GUI applications, the compiler run-time libraries provide standard mechanisms for receiving keyboard input in the case of desktop operating systems. Should you use an application framework such as the Microsoft Foundation Classes, the framework used must support the same standard input mechanisms. + Do not communicate directly with an input device; this may circumvent system messaging. For instance, in Windows, do not open the keyboard device driver directly. It is often the case that the windowing system needs to change the form and method for processing standard input mechanisms for proper application coexistence within the user interface framework. + Do not implement your own input device event queue mechanism; this may circumvent system messaging. Some assistive technologies use standard system facilities for simulating keyboard and mouse events. From the application's perspective, these events are no different than those generated by the user's actions. The Journal Playback Hooks (in both OS/2 and Windows) is one example of an application that feeds the standard event queues. + Operating system and application frameworks provide standard mechanisms for using standard output devices. In the case of common desktop operating systems such as Windows, OS/2, and Mac OS, standard APIs are provided for writing to the display and the multimedia subsystems. + Do not render text in the form of a bitmap before transferring to the screen, since some screen readers rely on the user agent's offscreen model. An offscreen model is rendered content created by an assistive technology that is based on the rendered content of another user agent. Assistive technologies that rely on an offscreen model generally construct it by intercepting standard system drawing calls. For example, in the case of display drivers, some screen readers are designed to monitor what is drawn on the screen by hooking drawing calls at different points in the drawing process. While knowing about the user agent's formatting may provide some useful information to assistive technologies, this document emphasizes access to the document object model rather than a particular rendering. For instance, instead of relying on system calls to draw text, assistive technologies should access the text through the document object model. + Common operating system 2D graphics engines and drawing libraries provide functions for drawing text to the screen. Examples of this are the Graphics Device Interface (GDI) for Windows, Graphics Programming Interface (GPI) for OS/2, and the X library (XLIB) for the X Windows System or Motif. + Do not communicate directly with an output device. + Do not draw directly to the video frame buffer. + Do not provide your own mechanism for generating pre-defined system sounds. + When writing textual information in a GUI operating system, use standard operating system APIs for drawing text. + Use operating system resources for rendering audio information. When doing so, do not take exclusive control of system audio resources. This could prevent an assistive technology such as a screen reader from speaking if they use software text-to-speech conversion. Also, in operating systems like Windows, a set of standard audio sound resources are provided to support standard sounds such as alerts. These preset sounds are used to activate SoundSentry graphical cues when a problem occurs; this benefits users with hearing disabilities. These cues may be manifested by flashing the desktop, active caption bar, or active window. It is important to use the standard mechanisms to generate audio feedback so that operating system or special assistive technologies can add additional functionality for users with hearing disabilities. + Enhance the functionality of standard system controls to improve accessibility where none is provided by responding to standard keyboard input mechanisms. For example provide keyboard navigation to menus and dialog box controls in the Apple Macintosh operating system. Another example is the Java Foundation Classes, where internal frames do not provide a keyboard mechanism to give them focus. In this case, you will need to add keyboard activation through the standard keyboard activation facility for Abstract Window Toolkit components. __________________________________________________________ 1.3 Implement the standard keyboard API of the operating system and ensure that every functionality available through the user interface is available through this API. This checkpoint does not apply when the operating system does not have a standard keyboard API. [Priority 1] (Checkpoint 1.3) Note: This checkpoint is an important special case of checkpoint 1.1. Refer also to checkpoint 10.8. Techniques: + Apply the techniques for checkpoint 1.1 to the keyboard. + Account for author-specified keyboard bindings, such as those specified by "accesskey" attribute in HTML 4.01 ([HTML4], section 17.11.2). + Allow the user to trigger event handlers (e.g., mouseover, mouseout, click, etc.) from the keyboard. + Test that all user interface components may be operable by software or devices that emulate a keyboard. Use SerialKeys and/or voice recognition software to test keyboard event emulation. __________________________________________________________ Checkpoints for user interface accessibility: 1.4 Ensure that the user can interact with all active elements in a device-independent manner. [Priority 1] (Checkpoint 1.4) Note: 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. This checkpoint is an important special case of checkpoint 1.1. Techniques: + Refer to checkpoint 1.1 and checkpoint 1.5. + Refer to image map techniques. + In the "Document Object Model (DOM) Level 2 Specification" [DOM2], 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 select 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. Refer also to checkpoint 5.3. __________________________________________________________ 1.5 Ensure every non-text message (e.g., prompt, alert, notification, etc.) that is part of the user agent's user interface also has a text equivalent in the user interface. This text equivalent must be available through an API. [Priority 1] (Checkpoint 1.5) Note: For example, if the user is notified of an event by an auditory cue, a text equivalent in the status bar would satisfy this checkpoint. Using accessible standard interface controls (per checkpoint 5.8) should make text equivalents available to assistive technologies for rendering as synthesized speech or Braille. Refer also to 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 alternate, 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: o Document proportions (numbers of lines, pages, width, etc.); o Number of elements of a particular type (e.g., tables, forms, and headings); o Whether the viewport is at the beginning or end of the document; o Size of document in bytes; o The number of controls in a form and controls in a form control group (e.g., FIELDSET in HTML). __________________________________________________________ Guideline 2. Ensure user access to all content. 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 equivalent alternatives for content, attributes, style sheets, etc. This checkpoint does not require that all content be available in every viewport. A document source view is part of a solution for providing access to content, but is not a sufficient solution on its own for all content. Refer to guideline 5 for more information about programmatic access to content. Techniques: + Some users benefit from concurrent access to primary and alternative content. 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 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 and 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 script languages. + Refer to the section on access to content. + Refer to the section on link techniques. + Refer to the section on table techniques. + Refer to the section on frame techniques. + Refer to 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: o Allow the user to configure that the expansions be used in place of the abbreviations, o Provide a list of all abbreviations in the document, with their expansions (a generated glossary of sorts) o Generate a link from an abbreviation to its expansion. o Allow the user to query the expansion of a selected or input abbreviation. o 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, allow the user to configure the user agent to pause the presentation automatically and await user input before proceeding. [Priority 1] (Checkpoint 2.2) Techniques: + As for other checkpoints, the user agent is not required to allow control of content properties that it cannot recognize. If timing effects are described through scripts in a manner that the user agent can recognize, it must allow the user to control the timing of the presentation. + 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 If content available in a viewport has equivalent alternatives, provide easy access to the alternative equivalents through at least one of the following mechanisms: (1) allowing configuration to render alternative instead of primary content; (2) allowing configuration to render alternative in addition to primary content; (3) allowing the user to select the primary content and then inspect its alternatives; (4) providing a direct link to the alternative in content, just before or after the primary content 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 by rendering them nearby, allowing the user to configure the user agent to render them in place of the image, or allowing the user to follow a readily available link to them. Techniques: + Refer to 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. How the user selects preferred natural language for captions in Real Player 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. Respect author-specified synchronization cues during rendering. [Priority 1] (Checkpoint 2.4) Techniques: + Captions and auditory descriptions may not make sense unless rendered synchronously with the primary 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 the primary audio track and the 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 caption text appears visually near the video for several second while the person reads the text. As the visual track continues, a new segment of the caption text is presented. However, a problem arises if the caption text is 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 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 "primary" presentation automatically pause? Some circumstances where this might occur include: # the segment of 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 "primary" 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.4 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. + 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 select 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 alternate tracks to provide equivalent alternatives. 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 equivalent alternatives, including auditory description and alternate visual tracks. + For other formats, at a minimum, users must be able to turn on and off auditory descriptions and captions. __________________________________________________________ 2.5 For non-text content that has no recognized text equivalent, allow configuration to generate repair text. If the non-text content is included by URI reference, base the repair text on the URI reference and content type of the Web resource. Otherwise, base the repair text on the name of the element including the non-text content. [Priority 2] (Checkpoint 2.5) 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 to repair the invalid content by generating a text equivalent. Refer also to checkpoint 2.6. 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 the HTTP 1.1 specification [RFC2616], section 3.2.1 for information about URI references. + 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 Refer to techniques for missing equivalent alternatives of content. + 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. __________________________________________________________ 2.6 When the author has specified an empty text equivalent for non-text content, do not generate one. [Priority 3] (Checkpoint 2.6) Note: Authors may provide an empty text equivalent (e.g., alt="") when one is required by specification, but the non-text content has no other function than pure decoration. Please refer to the Web Content Accessibility Guidelines 1.0 [WCAG10] for more details. Refer also to checkpoint 2.5. 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.7 Allow the user to configure the user agent not to render content marked up in a recognized but unsupported natural language. Indicate to the user in context that author-supplied content has not been rendered. [Priority 3] (Checkpoint 2.7) Note: For example, indicate that content in a particular language has not been rendered with a text substitute or with a graphical icon that has a text equivalent. Techniques: + 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 notification 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 notification 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.01 [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.01 ([HTML4], sections 8.2 and 8.2.4 respectively). Refer also to the Unicode standard [UNICODE]. + Refer to 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. + Refer to techniques for synthesized speech and checkpoint 5.4. __________________________________________________________ Guideline 3. Allow the user to configure the user agent not to render some content that may reduce accessibility. 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. [Priority 1] (Checkpoint 3.1) Note: Background images may make it difficult or impossible to read superimposed text. When background images are not rendered, user agents should render a solid background color. User agent may choose not to retrieve the background image resource at all. Refer also to checkpoint 4.3 and checkpoint 4.4. Note: This checkpoint only requires control of background for "two-layered renderings", i.e., one rendered background (other than a solid color) with all other content rendered "above it". Techniques: + Allow the user to turn off embedded or background images through the user agent user interface. Note that any equivalent alternatives 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. [Priority 1] (Checkpoint 3.2) Note: Audio may interfere with other sources of sound such as the output of a speech synthesizer. User agents may play the audio "silently". They may choose not to retrieve the resource at all. Refer also checkpoint 4.6, checkpoint 4.8 and checkpoint 4.9. Techniques: + None yet. __________________________________________________________ 3.3 Allow the user to configure the user agent not to render video. [Priority 1] (Checkpoint 3.3) Note: The user agent should render a still image or an icon to indicate that video has not been rendered. User agent may choose not to retrieve the resource at all. Techniques: + Render a still image in its place. + Implement the 'visibility' property of CSS 2 ([CSS2], section 11.2). A value of 'hidden' will cause a blank place-holder box to be rendered in place of the video on the screen while retaining the layout of the page. This differs from a value of 'none' for the 'display' property ([CSS2], section 9.2.5), which suppresses rendering of the video completely and may cause the layout of the page to be changed. + Allow the user to hide a video presentation from view, even though it continues to play in the background. __________________________________________________________ 3.4 Allow the user to configure the user agent to render animated or blinking text as motionless text. [Priority 1] (Checkpoint 3.4) 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 an moving text are: o The BLINK element in HTML. Note: The BLINK element is not defined by a W3C specification. o The MARQUEE element in HTML. Note: The MARQUEE element is not defined by a W3C specification. o The 'blink' value of the 'text-decoration' property in CSS ([CSS2], section 16.3.1). __________________________________________________________ 3.5 Allow the user to configure the user agent to render animated or blinking images as motionless images. [Priority 1] (Checkpoint 3.5) Note: Refer also to checkpoint 4.5 and checkpoint 4.6. 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 a still image in its place. __________________________________________________________ 3.6 Allow the user to configure the user agent not to execute scripts and applets. [Priority 1] (Checkpoint 3.6) 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: + Peak sensitivity to flickering or flashing occurs at 20 Hertz. + Refer to the section on script techniques __________________________________________________________ 3.7 Allow configuration so that author-specified "client-side redirects" (i.e., those initiated by the user agent, not the server) do not change content automatically. Allow the user to access the new content manually (e.g., by following a link). [Priority 2] (Checkpoint 3.7) Techniques: + Refer to the HTTP 1.1 specification [RFC2616] for information about redirection mechanisms. __________________________________________________________ 3.8 Allow configuration so that author-specified content refreshes do not change content automatically. Allow the user to access the new content manually (e.g., by activating a button or following a link). Advise the user to refresh content according to the same schedule as the automatic refresh, and indicate when the user has not yet refreshed content. [Priority 2] (Checkpoint 3.8) Techniques: + Alert the users to 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.9 Allow the user to configure the user agent not to render images. [Priority 2] (Checkpoint 3.9) 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. + Refer to techniques for checkpoint 3.1. __________________________________________________________ Guideline 4. Ensure user control of styles. In addition to the techniques below, refer also to the section on user control of style. Checkpoints for fonts and colors: 4.1 Allow the user to configure and control the reference size of text with an option to override author-specified user agent default text size. Make available the range of system font sizes. [Priority 1] (Checkpoint 4.1) Note: The reference size of 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 text size may vary among user agents. Control of text size may be accomplished in different ways, for example by allowing the user to change the font size or by allowing the user to zoom or magnify content. 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 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 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 text size on an element level (i.e., more precisely than globally). User style sheets allow such detailed configurations. + 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 the font family of all text, with an option to override author-specified and user agent default font families. Allow the user to select from among the range of system font families. [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. 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, for 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 the foreground color of all text, with an option to override author-specified and user agent default foreground colors. Allow the user to select from among the range of system colors. [Priority 1] (Checkpoint 4.3) Techniques: + Inherit foreground 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). + Allow the user to specify minimal contrast between foreground and background colors, adjusting colors dynamically to meet those requirements. + Allow the user to override author-specified foreground colors. __________________________________________________________ 4.4 Allow the user to configure the background color of all text, with an option to override author-specified and user agent default background colors. Allow the user to select from among the range of system colors. [Priority 1] (Checkpoint 4.4) Techniques: + Inherit background color information from user preferences specified for the operating system. + Implement the 'background-color' property (and other background properties) in CSS 2 ([CSS2], section 14.2.1). + Allow the user to override author-specified background colors. __________________________________________________________ Checkpoints for multimedia presentations, audio-only presentations, and visual-only presentations: 4.5 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 pre-recorded audio track including audio-only presentations, provide at least one setting between 75% - 80% of the original speed. For a synchronized multimedia presentation where the visual track may be slowed from 100% to to 80% of its original speed, synchronize the visual and audio tracks. Below 80%, the user agent is not required to render the audio track. [Priority 1] (Checkpoint 4.5) Refer also to checkpoint 2.4. 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. + When changing the rate of audio, avoid pitch distortion. + Some formats do not allow changes in playback rate. __________________________________________________________ 4.6 Allow the user to start, stop, pause, resume, fast forward, and fast reverse audio, video, and animations. [Priority 1] (Checkpoint 4.6) 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.7 Allow the user to position text transcripts, collated text transcripts, and captions on graphical displays. The range of available positions must be the same range available to the author according to specification. [Priority 1] (Checkpoint 4.7) 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. __________________________________________________________ Checkpoints for audio volume control: 4.8 Allow the user to configure and control the global audio volume. The user must be able to choose zero volume (i.e., silent). [Priority 1] (Checkpoint 4.8) Note: User agents should allow global 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.01 [HTML4]. __________________________________________________________ 4.9 Allow the user to control independently the volumes of distinct audio sources synchronized to play simultaneously. [Priority 1] (Checkpoint 4.9) Note: Refer also to checkpoint 4.11. Techniques: None. __________________________________________________________ Checkpoints for synthesized speech: Refer also to techniques for synthesized speech. 4.10 Allow the user to configure and control synthesized speech playback rate according to the full range offered by the speech synthesizer. The lower bound for this range must be at most 120 words per minute. The upper bound for this range must be at least 400 words per minute. The user must be able to increase or decrease the playback rate in increments of 5% of the current playback rate. [Priority 1] (Checkpoint 4.10) Techniques: + Use synthesized speech mechanisms provided by the operating system. + Implement the CSS 2 'speech-rate' property ([CSS2], section 19.8). __________________________________________________________ 4.11 Allow the user to control the synthesized speech volume independently of other sources of audio. [Priority 1] (Checkpoint 4.11) Note: Refer also to checkpoint 4.9. 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.12 Allow the user to configure synthesized voice gender, pitch, pitch range, stress, richness, and control of spelling, punctuation, and number processing according to the full range of values offered by the speech synthesizer. [Priority 2] (Checkpoint 4.12) Note: This list of voice characteristic properties is based on the list in section 19.8 of Cascading Style Sheets Level 2 [CSS2]. Ranges of values for these properties may vary among speech synthesizers. 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.13 Allow the user to select from available author and user style sheets or to ignore them. [Priority 1] (Checkpoint 4.13) 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). __________________________________________________________ 4.14 Allow the user to configure how the selection is highlighted (e.g., foreground and background color). Offer at least three rendering options, including colors and fonts. Allow the user to select from among the range of system colors and fonts. [Priority 1] ( Checkpoint 4.14) Techniques: + As an sample implementation, note that Netscape Navigator [NAVIGATOR] for X Windows uses resources to control the selection colors (*selectForeground and *selectBackground). + Implement the CSS 2 "HighLightText and "Highlight" predefined color values ([CSS2], section 18.2). + Inherit selection information from user's settings for the operating system. __________________________________________________________ 4.15 Allow the user to configure how the content focus is highlighted (e.g., foreground and background color). Offer at least three rendering options, including colors and fonts. Allow the user to select from among the range of system colors and fonts. The default focus highlight mechanism must be different from the default selection highlight mechanism. [Priority 1] (Checkpoint 4.15) Techniques: + Implement the CSS 2 ':focus' pseudo-class and dynamic outlines and focus of CSS 2 ([CSS2], sections 5.11.3 and 18.4.1, respectively). For example, the following rule will cause links with focus to appear with a blue background and yellow text. A:focus { background: blue; color: yellow } The following rule will cause TEXTAREA elements with focus to appear with a particular focus outline: TEXTAREA:focus { outline: thick black solid } + Inherit focus information from user's settings for the operating system. + Test the user agent to ensure that individuals who have low vision and use screen magnification software are able to follow highlighted item(s). __________________________________________________________ 4.16 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.16) Techniques: + 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 notify 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, notify 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 quickly return to the point of regard in the duplicate viewport. There are other techniques for accomplishing this (e.g., "registers" in emacs). + 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.17 Allow the user to configure the user agent so that after one viewport is open, no other viewports open except as the result of explicit user request. [Priority 2] (Checkpoint 4.17) Note: Some users may become disoriented when there are too many open viewports. In addition to configuration, user agents should allow the user to control the number of open viewports by selecting and closing them. Following an author-specified link that opens a new viewport does not constitute an explicit request from the user. Refer also to checkpoint 4.16 and checkpoint 5.5. Techniques: + 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. __________________________________________________________ Guideline 5. Observe system conventions and standard interfaces. Checkpoints for communication with other software: 5.1 Provide programmatic read access to HTML and XML content by conforming to the W3C Document Object Model (DOM) Level 2 Core and HTML modules and exporting the interfaces they define. [Priority 1] (Checkpoint 5.1) Note: These modules are defined in DOM Level 2 [DOM2], chapters 1 and 2. Please refer to that specification for information about which versions of HTML and XML are supported and for the definition of a "read-only" DOM. This checkpoint is an important special case of checkpoint 2.1. For content other than HTML and XML, refer to checkpoint 5.3. 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. + Refer to 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 W3C Document Object Model (DOM) Level 2 Core and HTML modules and exporting the interfaces they define. [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 DOM APIs. These modules are defined in DOM Level 2 [DOM2], chapters 1 and 2. Please refer to DOM Level 2 [DOM2] for information about which versions of HTML and XML are supported. This checkpoint is an important special case of checkpoint 2.1. For markup languages other than HTML and XML, refer to checkpoint 5.3. Techniques: + Refer to 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. This checkpoint is an important special case of checkpoint 2.1. Techniques: + Refer to techniques for checkpoint 5.4. __________________________________________________________ 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 for the 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 promote accessibility include: o Microsoft Active Accessibility ([MSAA]) in Windows 95/98/NT versions. o 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 [BHO]. __________________________________________________________ 5.5 Using standard APIs, provide programmatic notification of changes to content and user interface controls (including selection, content focus, and user interface focus). [Priority 1] (Checkpoint 5.5) Note: Use the standard APIs required by guideline 5. Techniques: + Refer to "mutation events" in DOM Level 2 [DOM2]. This module of DOM 2 allows assistive technologies to be informed of changes to the document tree. + Refer also to information about monitoring HTML events through the document object model in Internet Explorer [IE-WIN]. __________________________________________________________ 5.6 Ensure that programmatic exchanges proceed in a timely manner. [Priority 2] (Checkpoint 5.6) Note: For example, the programmatic exchange of information required by other checkpoints in this document must be efficient enough to prevent information loss, a risk when changes to content or user interface occur more quickly than the communication of those changes. The techniques for this checkpoint explain how developers can reduce communication delays, e.g., to ensure that assistive technologies have timely access to the document object model and other information needed for accessibility. Techniques: + Please refer to the appendix that explains how to load assistive technologies for DOM access. + Alert the user when information is being lost due to communication delays. __________________________________________________________ 5.7 For user agents that support Cascading Style Sheets ([CSS1], [CSS2]), provide programmatic access to CSS style sheets by conforming to the W3C Document Object Model (DOM) Level 2 CSS module and exporting the interfaces it defines. [Priority 3] (Checkpoint 5.7) Note: This module is defined in DOM Level 2 [DOM2], chapter 5. Please refer to that specification for information about which versions of CSS are supported. This checkpoint is an important special case of checkpoint 2.1. Techniques: + Refer to techniques for checkpoint 5.1. __________________________________________________________ Checkpoints for user interface accessibility: 5.8 Follow operating system conventions that benefit accessibility. In particular, follow conventions for user interface design, keyboard configuration, product installation, and documentation. [Priority 2] (Checkpoint 5.8) Note: Operating system conventions that benefit accessibility are those described in this document and in platform-specific accessibility guidelines. Some of these conventions (e.g., sticky keys, mouse keys, show sounds, etc.) are discussed in the Techniques document [UAAG10-TECHS]. Refer also to checkpoint 10.2. Techniques: + Refer to techniques for checkpoint 1.2. + Refer to techniques for checkpoint 5.4. + Refer to techniques for checkpoint 10.2. + Follow operating system and application environment (e.g., Java) conventions for loading assistive technologies. Refer to the appendix on loading assistive technologies for DOM access for information about how an assistive technology developer can load its software into a Java Virtual Machine. + Ensure that any online services (e.g., automated update facilities, download-and-install functionalities, sniff-and-fill forms, etc.) observe relevant operating system conventions concerning device independence and accessibility (as well as the Web Content Accessibility Guidelines 1.0 [WCAG10]). + Evaluate the standard interface controls on the target platform against any built-in operating system accessibility functions (refer to the appendix on accessibility features of some operating systems). Ensure that the user agent operates properly with all these functions. Here is a sample of features to consider: o Microsoft Windows offers an accessibility function called "High Contrast". Standard window classes and controls automatically support this setting. However, applications created with custom classes or controls work with the "GetSysColor" API to ensure compatibility with High Contrast. o Apple Macintosh offers an accessibility function called "Sticky Keys". Sticky Keys operate with keys the operating system recognizes as modifier keys, and therefore a custom control should not attempt to define a new modifier key. o Maintain consistency in the user interface between versions of the software. Consistency is less important than improved general accessibility and usability, but developers should make changes conservatively to the layout of user interface controls, the behavior of existing functionalities, and the default keyboard configuration. + Follow accessibility guidelines for specific platforms: o "Macintosh Human Interface Guidelines" [APPLE-HI] o "IBM Guidelines for Writing Accessible Applications Using 100% Pure Java" [JAVA-ACCESS]. o "An Inter-client Exchange (ICE) Rendezvous Mechanism for X Window System Clients" [ICE-RAP]. o "Information for Developers About Microsoft Active Accessibility" [MSAA]. o "The Inter-Client communication conventions manual" [ICCCM]. o "Lotus Notes accessibility guidelines" [NOTES-ACCESS]. o "Java accessibility guidelines and checklist" [JAVA-CHECKLIST]. o "The Java Tutorial. Trail: Creating a GUI with JFC/Swing" [JAVA-TUT]. o "The Microsoft Windows Guidelines for Accessible Software Design" [MS-SOFTWARE]. + Follow general guidelines for producing accessible software: o "Accessibility for applications designers" [MS-ENABLE]. o "Application Software Design Guidelines" [TRACE-REF]. o Articles and papers from Sun Microsystems about accessibility [SUN-DESIGN]. o "EITAAC Desktop Software standards" [EITAAC]. o "Requirements for Accessible Software Design" [ED-DEPT]. o "Software Accessibility" [IBM-ACCESS]. o Towards Accessible Human-Computer Interaction" [SUN-HCI]. o "What is Accessible Software" [WHAT-IS]. o Accessibility guidelines for Unix and X Window applications [XGUIDELINES]. __________________________________________________________ Guideline 6. Implement accessible specifications. Checkpoints for content accessibility: 6.1 Implement the accessibility features of all supported specifications (markup languages, style sheet languages, metadata languages, graphics formats, etc.). Accessibility features are those identified in the specification and those features of the specification that support requirements of the "Web Content Accessibility Guidelines 1.0" [WCAG10], the "Authoring Tool Accessibility Guidelines 1.0" [ATAG10], and the current document. [Priority 1] (Checkpoint 6.1) Techniques: + Make obvious to users features that are known to promote accessibility. Make them easy to find in the user interface and in documentation. + Some specifications include optional features (not required for conformance to the specification). If an optional feature is likely to cause accessibility problems, developers should either ensure that the user can turn off the feature or they not implement the feature. + Refer to the "Accessibility Features of CSS" [CSS-ACCESS]. Note that CSS 2 includes properties for configuring synthesized speech styles. + Refer to the "Accessibility Features of SMIL" [SMIL-ACCESS]. + Refer to the following list of accessibility features of HTML 4.01 [HTML4] (in addition to those described in techniques for checkpoint 2.1): o The CAPTION element (section 11.2.2) for rich table captions. o Table elements THEAD, TBODY, and TFOOT (section 11.2.3), COLGROUP and COL (section 11.2.4) that group table rows and columns into meaningful sections. o Attributes "scope", "headers", and "axis" (section 11.2.6) which are semantically significant labels that non-graphical user agents may use to render a table in a linear fashion. o The "tabindex" attribute (section 17.11.1) for assigning the order of keyboard navigation within a document. o The "accesskey" attribute (section 17.11.2) for assigning keyboard commands to active components such as links and form controls. + For information about the Sun Microsystems Java Accessibility API in Java JDK, refer to [JAVAAPI]. + For information about captioning for the Synchronized Accessible Multimedia Interchange (SAMI), refer to [SAMI]. __________________________________________________________ 6.2 Use and conform to W3C Recommendations when they are available and appropriate for a task. [Priority 2] (Checkpoint 6.2) Note: For instance, for markup, implement HTML 4.01 [HTML4], XHTML 1.0 [XHTML10], 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 information about programmatic access to HTML and XML content, refer to guideline 5. Note: For reasons of backward compatibility, user agents should continue to implement deprecated features of specifications. The current guidelines refer to some deprecated language features that do not necessarily promote accessibility but are widely deployed. Information about deprecated language features is generally part of the language's specification. Techniques: + The requirement of this checkpoint is to implement at least one W3C Recommendation that is available and appropriate for a particular task. For example, user agents would satisfy this checkpoint by implementing the Portable Network Graphics 1.0 specification [PNG] for raster images. In addition, user agents may implement other image formats such as JPEG, GIF, etc. + If more than one version or level of a W3C Recommendation is appropriate for a particular task, user agents are encouraged to implement the latest version. + Specifications that become W3C Recommendations after a user agent's development cycles permit input are not considered "available" in time for that version of the user agent. + Each specification defines what conformance means for that specification. + W3C make available validation services to promote the proper usage and implementation of specifications. Refer to the: o HTML and XML validator service [VALIDATOR]. o CSS validator service [CSSVALIDATOR]. __________________________________________________________ Guideline 7. Provide navigation mechanisms. Checkpoints for user interface accessibility: 7.1 Allow the user to navigate among all viewports (including frames). [Priority 1] (Checkpoint 7.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. Navigation among all viewports implies at least allowing the user to cycle through all viewports. Navigating into a viewport makes it the current viewport. Techniques: + Refer to the frame techniques. Some operating systems provide a means to navigate among all open windows using multiple input devices (e.g., keyboard and mouse). This technique would suffice for switching among user agent viewports that are separate windows. However, user agents may also provide a mechanism to shift the user interface focus among user agent windows, independent of the standard operating system mechanism. __________________________________________________________ 7.2 Associate a point of regard with each state in a viewport's browsing history and when the user returns to a state in the history, restore the associated point of regard. [Priority 1] (Checkpoint 7.2) Note: For example, when the user navigates from one viewport to another (per checkpoint 7.1) and back, the point of regard should be restored. Techniques: + When the user returns to a page after following a link, restore content focus to that link. + If the user agent allows the user to browse multimedia or audio-only presentations, when the user leaves one presentation for another, pause the presentation. When the user returns to a previous presentation, allow the user to resume the presentation where it was paused (i.e., return the point of regard to the same place in space and time). Note: This may be done for a presentation that is available "completely" but not for a "live" stream or any part of a presentation that continues to run in the background. Allow the user to configure whether leaving a viewport pauses a multimedia presentation. + Refer to the HTTP 1.1 specification for information about history mechanisms ([RFC2616], section 13.13). __________________________________________________________ 7.3 Allow the user to navigate all active elements. If the author has not specified a navigation order, allow at least forward sequential navigation of elements, in document order. [Priority 1] (Checkpoint 7.3) Note: Navigation may include non-active elements in addition to active elements. This checkpoint is an important special case of checkpoint 7.6. Techniques: Sequential navigation techniques + Allow the user to navigate sequentially all active elements by repeatedly pressing a single key. Many user agents today allow users to navigate sequentially by repeating a key combination -- for example, using the Tab key for forward navigation and Shift-Tab for reverse navigation. Because the Tab key is typically on one side of the keyboard while arrow keys are located on the other, users should be allowed to configure the user agent so that sequential navigation is possible with keys that are physically closer to the arrow keys. Refer also to checkpoint 10.4. + Provide other sequential navigation mechanisms for particular element types or semantic units, e.g., "Find the next table" or "Find the previous form." For more information about sequential navigation of form controls and form submission, refer to techniques for checkpoint 9.2. + Maintain a logical element navigation order. For instance, users may use the keyboard to navigate among elements or element groups using the arrow keys within a group of elements. One example of a group of elements is a set of radio buttons. Users should be able to navigate to the group of buttons, then be able to select each button in the group. Similarly, allow users to navigate from table to table, but also among the cells within a given table (up, down, left, right, etc.). + The default sequential navigation order should respect the conventions of the natural language of the document. Thus, for most left-to-right languages, the usual navigation order is top-to-bottom and left-to-right. For right-to-left languages, the order would be top-to-bottom and right-to-left. + Respect author-specified information about navigation order (e.g., the "tabindex" attribute in HTML 4 [HTML4], section 17.11.1). Allow users to override the author-specified navigation order (e.g., by offering an alphabetized view of links or other orderings). + Give the users the option of navigating to and activating a link, or just moving the content focus to the link. First-time users of a page may want access to link text before deciding whether to follow the link (activate). More experienced users of a page might prefer to follow the link directly, without the intervening content focus step. + In Java, a component is part of the sequential navigation order when added to a panel and its isFocusTraversable method returns true. A component can be removed from the navigation order by extending the component, overloading this method, and returning false. JAWS for Windows Links List view This image shows how JAWS for Windows [JFW] allows users to navigate to links in a document and activate them independently. Users may also configure the user agent to navigate visited links, unvisited links, or both. Users may also change the sequential navigation order, sorting links alphabetically or leaving them in the logical tabbing order. The focus in the links view follows the focus in the primary view. Direct navigation techniques + Excessive use of sequential navigation can reduce the usability of software for both disabled and non-disabled users. + Some useful types of direct navigation include: navigation based on position (e.g., all links are numbered by the user agent), navigation based on element content (e.g., the first letter of text content), direct navigation to a table cell by its row/column position, and searching (e.g., based on form control text, associated labels, or form control names). + Document available direct navigation mechanisms. __________________________________________________________ 7.4 Allow the user to choose to navigate only active elements. If the author has not specified a navigation order, allow at least forward and reverse sequential navigation of active elements, in document order. [Priority 2] (Checkpoint 7.4) Techniques: + Apply the techniques of checkpoint 7.3 to active elements only. __________________________________________________________ 7.5 Allow the user to search for rendered text content, including rendered text equivalents. Allow the user to start a forward search from a location in content selected or focused by the user. After a match, allow searching from location of the match. Provide a case-insensitive search option when applicable to the natural language of text. [Priority 2] (Checkpoint 7.5) Note: The default search starting point should be the beginning of content. Use operating system conventions for marking the result of a search (e.g., selection or content focus). Techniques: + Allow users to search for text content (element content and attribute values). + Allow users to search forward and backward from the point of regard, the beginning of document, or the end of the document. + Allow users to search a document source view. + For forms, allow users to find controls that must be changed by the user before submitting the form. Allow users to search the element content of controls (where applicable) and any label text. + Allow the user to search among just text equivalents of other content. + For multimedia presentations: o Allow users to search and examine time-dependent media elements and links in a time-independent manner. For example, present a static list of time-dependent links. o Allow users to find all media elements active at a particular time in the presentation. o Allow users to view a list of all media elements or links of the presentations sorted by start or end time or alphabetically. o For frames, allow users to search for content in all frames, without having to be in a particular frame. o It may be confusing to allow users to search for text content that is not rendered (and thus that they have not viewed). If this type of search is possible, notify the user of this particular search mode. __________________________________________________________ 7.6 Allow the user to navigate efficiently to and among important structural elements identified by the author. For markup languages with known semantics, allow forward sequential navigation to important structural elements. For other markup languages, allow at least forward sequential navigation of the document object, in document order. In HTML 4 [HTML4], the list of important elements is: A, ADDRESS, BUTTON, FIELDSET, DD, DIV, DL, DT, FORM, FRAME, H1-H6, IMAGE, INPUT, LI, MAP, OBJECT, OL, OPTGROUP, OPTION, P, TABLE, TEXTAREA, and UL. In SMIL 1.0 [SMIL], the list of important elements is: a, anchor, par, seq, and switch. In SVG 1.0 [SVG], the important elements are a and g. [Priority 2] (Checkpoint 7.6) Note: Structured navigation of headings, tables, forms, lists, etc., is most effective when available in conjunction with a configurable view (checkpoint 8.4 and checkpoint 8.5). User agents should follow operating system conventions for indicating navigation progress (e.g., selection or content focus). Techniques: User agents should construct the navigation view with the goal of breaking content into sensible pieces according to the author's design. In most cases, user agents should not break down content into individual elements for navigation; element-by-element navigation of the document object does not meet the goal of facilitating navigation to important pieces of content. Instead, user agents are expected to construct the navigation view from author-supplied markup. For those languages with known conventions for identifying important components, user agents should construct the navigation tree from those components, allowing users to navigate to them, skip them, or navigate into them. In HTML, important elements including headings, tables, forms, DIV elements (notably with a "title" attribute set), navigation mechanisms (marked up with MAP), and lists. HTML also allows authors to specify keyboard configurations ("accesskey", "tabindex"), which can serve as hints about what the author considers important. Tables and forms illustrate the utility of a recursive navigation mechanism. The user should be able to navigate to tables, then change "scope" and navigate within the cells of that table. Nested tables (a table within the cell of another table) fit nicely within this scheme. However, the headers of an nested table may provide important context for the cells of the same row(s) or column(s) containing the nested table. The same ideas apply to forms: users should be able to navigate to a form, then among the controls within that form. In SVG [SVG], the "g" element signifies a grouping and should be considered when constructing the navigation view. In SMIL, "par", "seq", and "switch" provide information that may be useful for identifying significant components of content. User agents should allow users to: 1. Navigate to a piece of content that the author has identified as important according to the markup language specification and conventional usage. In HTML, for example, this includes headings, forms, tables, navigation mechanisms, and lists. 2. Navigate past that piece of content (i.e., avoid the details of that component). 3. Navigate into that piece of content (i.e., chose to view the details of that component). 4. Change the navigation view as they go, expanding and contracting portions of content that they wish to examine or ignore. This will speed up navigation and promote orientation at the same time. + Use the DOM [DOM2] as the basis of structured navigation (e.g., a postorder traversal). However, for well-known markup languages such as HTML, structured navigation should take advantage of the structure of the source tree and what is rendered. + Allow navigation based on commonly understood document models, even if they do not adhere strictly to a Document Type Definition (DTD). For instance, in HTML, although headings (H1-H6) are not containers, they may be treated as such for the purpose of navigation. Note that they should be properly nested. + Allow the user to limit navigation to the cells of a table (notably left and right within a row and up and down within a column). Navigation techniques include keyboard navigation from cell to cell (e.g., using the arrow keys) and page up/down scrolling. Refer to the section on table navigation. + Allow depth-first as well as breadth-first navigation. + Alert the user when navigation has led to the beginning or end of a structure (e.g., end of a list, end of a form, table row or column end, etc.). Refer also to checkpoint 1.5. + Provide context-sensitive navigation. For instance, when the user navigates to a list or table, provide locally useful navigation mechanisms (e.g., within a table, cell-by-cell navigation) using similar input commands. + From a given element, allow navigation to the next or previous sibling, up to the parent, and to the end of an element. + Allow users to navigate synchronized multimedia presentations. Refer also to checkpoint 4.6. + Allow the user to navigate characters, words, sentences, paragraphs, screenfuls, and other pieces of text content that depend on natural language. This benefits users of speech-based user agents and has been implemented by several screen readers, including Winvision [WINVISION], Window-Eyes [WINDOWEYES], and JAWS for Windows [JFW]. + Allow users to skip author-specified navigation mechanisms such as navigation bars. For instance, navigation bars at the top of each page at a Web site may force users with screen readers or some physical disabilities to wade through many links before reaching the important information on the page. User agents may facilitate browsing for these users by allowing them to skip recognized navigation bars (e.g., through a configuration option). Some techniques for this include: 1. Providing a functionality to jump to the first non-link content. 2. In HTML, the MAP element may be used to mark up a navigation bar (even when there is no associated image). Thus, users might ask that MAP elements not be rendered in order to hide links inside the MAP element. User agents might allow users to hide MAP elements selectively. For example, hide any MAP element with a "title" attribute specified. Note: Starting in HTML 4.01, the MAP element allows block content, not just AREA elements. + The following is a summary of ideas provided by the National Information Standards Organization [NISO]: A talking book's "Navigation Control Center" (NCC) resembles a traditional table of contents, but it is more. It contains links to all headings at all levels in the book, links to all pages, and links to any items that the reader has chosen not to have read. For example, the reader may have turned off the automatic reading of footnotes. To allow the user to retrieve that information quickly, the reference to the footnote is placed in the NCC and the reader can go to the reference, understand the context for the footnote, and then read the footnote. Once the reader is at a desired location and wishes to begin reading, the navigation process changes. Of course, the reader may elect to read sequentially, but often some navigation is required (e.g., frequently people navigate forward or backward one word or character at a time). Moving from one sentence or paragraph at a time is also needed. This type of local navigation is different from the global navigation used to get to the location of what you want to read. It is frequently desirable to move from one block element to the next. For example, moving from a paragraph to the next block element which may be a list, blockquote, or sidebar is the normally expected mechanism for local navigation. __________________________________________________________ 7.7 Allow the user to configure and control the set of elements navigable according to checkpoint 7.6 by allowing inclusion and exclusion of element types in the navigation sequence. [Priority 3] (Checkpoint 7.7) Note: For example, allow the user to navigate only paragraphs, or only headings and paragraphs, etc. Techniques: + Allow the user to navigate by element type. + Allow the user to navigate HTML elements that share the same "class" attribute. + Allow the user to expand or shrink portions of the document structure (configure detail level) for faster access to important parts of content. __________________________________________________________ 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 author-specified relationships among the table cells and headers. [Priority 1] (Checkpoint 8.1) Note: Depending on the table, some techniques may be more efficient than others for conveying data relationships. For many tables, graphical user agents may satisfy this checkpoint by rendering a table as a two dimensional grid and by ensuring that users can find headers associated with cells. However, for large tables or small viewports, allowing the user to query cells for information about related headers may improve access. Refer also to checkpoint 5.3. This checkpoint is an important special case of checkpoint 2.1. Techniques: + The more complex the table, the more clues to table structure are needed. Make available information summarizing table structure, including any table head and foot rows, and possible row grouping into multiple table bodies, column groups, header cells and how they relate to data cells, the grouping and spanning of rows and columns that apply to qualify any cell value, cell position information, table dimensions, etc. + Provide information about table headers, how headers relate to cells, table summary information, cell position information, table dimensions, etc. + In HTML, beyond the TR, TH, and TD elements, the table attributes "summary", "abbr", "headers", "scope", and "axis" provide information about relationships among cells and headers. For more information, refer to the section on table techniques. + Refer to the THEAD, TBODY, and TFOOT elements of HTML 4 ([HTML4], section 11.2.3). These elements may be "fixed" to the screen (or repeated on paper) with the 'fixed' value of the CSS2 'position' property ([CSS2], section 9.3.1). When these elements are used by authors, users can scroll through data while retaining headers and footers "in view". + When rendering a table serially, allow the user to specify how cell header information should be rendered before cell data information. Some possibilities are illustrated by the CSS2 'speak-header' property ([CSS2], section 17.7.1). Internet Explorer context menu item to display table cell header information This image shows how Internet Explorer [IE-WIN] provides cell header information through the context menu. __________________________________________________________ 8.2 Render recently visited links in a distinct style. Allow the user to configure this style and offer at least three rendering options, including colors and fonts. Allow the user to select from among the range of system colors and fonts. [Priority 2] (Checkpoint 8.2) Note: Do not use color as the only distinguishing factor between visited and unvisited links as some users may not perceive colors and some devices may not render them. This checkpoint is an important special case of checkpoint 8.6. Techniques: + Do not rely on color alone. Refer to the visited links example in the section on generated content techniques. + Refer to techniques for checkpoint 7.3. + Refer to the section on link techniques. The Opera dialog box for configuring the rendering of links This image shows how Opera [OPERA] allows the user to configure link rendering, including the identification of visited links. __________________________________________________________ 8.3 Render in a distinct style those links that have been marked up to indicate that following them will involve a fee. Allow the user to configure this style and offer at least three rendering options, including colors and fonts. Allow the user to select from among the range of system colors and fonts. [Priority 2] (Checkpoint 8.3) Note: This checkpoint is an important special case of checkpoint 8.6. Techniques: + The W3C specification "Common Markup for micropayment per-fee-links" [MICROPAYMENT] describes how authors may mark up micropayment information in an interoperable manner. + Use standard, accessible interface controls to present information about fees and to prompt the user to confirm payment. + For a link that has content focus, allow the user to query the link for fee information (e.g., by activating a menu or key stroke). + Refer to the section on link techniques. __________________________________________________________ 8.4 Make available to the user an "outline" view of content, composed of text labels for important structural elements (e.g., heading text, table titles, form titles, etc.). The set of important structural elements is the same required by checkpoint 7.6. [Priority 2] (Checkpoint 8.4) Note: This checkpoint is meant to allow the user to simplify the view of content by hiding some content selectively. For example, for each frame in a frameset, provide a table of contents composed of headings (e.g., the H1 - H6 elements in HTML) where each entry in the table of contents links to the heading in the document. This checkpoint does not require that the outline view be navigable, but this is recommended; refer to checkpoint 7.6. For those elements that do not have associated text titles or labels, the user agent should use generate a brief text label (e.g., from content, the element type, etc.). Techniques: + Allow the user to expand or shrink portions of the outline view (configure detail level) for faster access to important parts of content. + Hide portions of content by using the CSS 'display' and 'visibility' properties ([CSS2], sections 9.2.5 and 11.2, respectively). + Provide a structured view of form controls (e.g., those grouped by LEGEND or OPTGROUP in HTML) along with their labels. + Refer to structured navigation techniques for checkpoint 7.6. + For documents that do not use structure properly, user agents may attempt to create an outline based on the rendering of elements and heuristics about what elements may indicate about document structure. Amaya table of contents view This image shows the table of contents view provided by Amaya [AMAYA]. This view is synchronized with the "primary" view so that users may navigate in one viewport and the focus follows in the other. An entry in the table of contents with a target icon means that the heading in the document has an associated anchor. __________________________________________________________ 8.5 Allow the user to configure and control the outline view of checkpoint 8.4 to include and exclude element types. [Priority 3] (Checkpoint 8.5) Note: For example, allow the user to configure the level of detail of the outline. Refer also to checkpoint 8.4 and checkpoint 5.4. Techniques: + The CSS 'display' and 'visibility' properties ([CSS2], sections 9.2.5 and 11.2, respectively), allow the user to override the default settings in user style sheets. Example. The following CSS 2 style sheet will turn the display off of all HTML elements inside the BODY element except heading elements: Another approach would be to use class selectors to identify those elements to hide or display. End example. __________________________________________________________ 8.6 To help the user decide whether to traverse a link, make available the following information about it: link content, link title, whether the link is internal to the local resource, whether the user has traversed the link recently, whether traversing it may involve a fee, and information about the type, size, and natural language of linked Web resources. The user agent is not required to compute or make available information that requires retrieval of linked Web resources. [Priority 3] (Checkpoint 8.6) Techniques: + Some markup languages allow authors to provide hints about the nature of linked content (e.g., in HTML 4 [HTML4], the "hreflang" and "type" attributes on the A element). Specifications should indicate when this type of information is a hint from the author and when these hints may be overridden by another mechanism (e.g., by HTTP headers in the case of HTML). User agent developers should make the author's hints available to the user (prior to retrieving a resource), but should provide definitive information once available. + User agents may use HTTP HEAD rather than GET for information about size, language, etc. Refer to RFC 2616 [RFC2616], section 9.3 + For information about content size in HTTP/1.1, refer to RFC 2616 [RFC2616], section 14.13. User agents are not expected to compute content size recursively (i.e., by adding the sizes of resources referenced by URIs within another resource). + For information about content language in HTTP/1.1, refer to RFC 2616 [RFC2616], section 14.12. + For information about content type in HTTP/1.1, refer to RFC 2616 [RFC2616], section 14.17. + Links may be simple (e.g., HTML links) or more complex, such as those defined by the XML Linking Language (XLink) [XLINK]. + Refer to RFC 2616 [RFC2616], section 14.13. + The scope of "recently followed link" depends on the user agent. The user agent may allow the user to configure this parameter, and should allow the user to reset all links as "not followed recently". + User agents should cache information determined as the result of retrieving a Web resource and should make it available to the user. Refer to HTTP/1.1 caching mechanisms described RFC 2616 [RFC2616], section 13. + For a link that has content focus, allow the user to query the link for information (e.g., by activating a menu or key stroke). + Refer to the section on link techniques. __________________________________________________________ Checkpoints for user interface accessibility: 8.7 Implement selection, content focus, and user interface focus mechanisms. Implement them according to system conventions per checkpoint 5.8. [Priority 1] (Checkpoint 8.7) Note: This checkpoints refers to the semantics of the selection and focus; requirements for rendering are addressed by checkpoint 8.8, checkpoint 4.15, and checkpoint 4.14. Refer also to checkpoint 7.1. Techniques: + Refer to Selection and Partial Selection of DOM Level 2 ([DOM2], section 8.2.2). + For information about focus in the Motif environment (under X Windows), refer to the OSF/Motif Style Guide [MOTIF]. __________________________________________________________ 8.8 Provide a mechanism for highlighting and identifying (through a standard interface where available) the current viewport, selection, and content focus. [Priority 1] ( Checkpoint 8.8) Note: This includes highlighting and identifying frames. This checkpoint is an important special case of checkpoint 1.1. Refer also to checkpoint 8.6. Techniques: + If colors are used to highlight the current viewport, selection, or content focus, allow the user to configure these colors. Do not rely on color alone. + Provide a setting that causes a window that is the current viewport to pop to the foreground. + Provide a setting that causes a window that is the current viewport to be maximized automatically. For example, maximize the parent window of the browser when launched, and maximize each child window automatically when it receives focus. Maximizing does not necessarily mean occupying the whole screen or parent window; it means expanding the current window so that users have to scroll horizontally or vertically as little as possible. + If the current viewport is a frame or the user does not want windows to pop to the foreground, use colors, reverse videos, or other graphical clues to indicate the current viewport. + For speech or Braille output, use the frame or window title to identify the current viewport. Announce changes in the current viewport. + Use operating system conventions, for specifying selection and content focus (e.g., schemes in Windows). + Implement the ':hover', ':active', and ':focus' pseudo-classes of CSS 2 ([CSS2], section 5.11.3). This allows users to modify content focus rendering with user style sheets. + Refer to the section on frame techniques. Example of a solid line border used to indicate the content focus in Opera 3.60 This image shows how Opera [OPERA] uses a solid line border to indicate content focus. Example of system highlight colors used to indicate the content focus by the accessible browser project This image shows how the Accessible Web Browser [AWB] uses the system highlight colors to indicate content focus. __________________________________________________________ 8.9 Provide a mechanism for highlighting and identifying active elements. [Priority 2] (Checkpoint 8.9) Note: On most systems, the focus is used to identify and highlight active elements. Techniques: + Allow users to configure highlighting preferences. + Do not rely on color alone to identify active elements. + Implement the ':hover', ':active', and ':focus' pseudo-classes of CSS 2 ([CSS2], section 5.11.3). + Implement CSS attribute selectors to match elements with associated scripts ([CSS2], section 5.8). __________________________________________________________ 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] (Checkpoint 9.1) Note: For example, if users navigating links move to a portion of the document outside the viewport, the viewport should scroll to include the new location of the focus. 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 synchronized explicitly, changes to selection or focus in one viewport should not affect the selection or focus in another viewport. __________________________________________________________ 9.2 Allow configuration so the user is prompted to confirm any form submission not caused by explicit activation of a form submit control. [Priority 2] (Checkpoint 9.2) Note: 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. The user agent may satisfy this checkpoint by prompting the user to confirm all form submissions. Techniques: + In HTML 4 [HTML4], form submit controls are the INPUT element (section 17.4) with type="submit" and type="image", and the BUTTON element (section 17.5) with type="submit". + Allow the user to configure script-based submission (e.g., triggered by an "onChange" event). For instance, allow these settings: 1. Do not allow script-based submission. 2. Allow script-based submission after confirmation from the user. 3. Allow script-based submission without prompting the user (but not by default). + Users who navigate a document serially may think that the submit button in a form is the "last" control they need to complete before submitting the form. Therefore, for forms in which additional controls follow a submit button, if those controls have not been completed, inform the user and ask for confirmation (or completion) before submission. + pwWebSpeak [PWWEBSPEAK] generates an explicit form submit button when the author has not provided one. __________________________________________________________ 9.3 Indicate the relative position of the viewport in rendered content (e.g., the proportion of an audio or video clip that has been played, the proportion of a Web page that has been viewed, etc.). [Priority 3] (Checkpoint 9.3) Note: The user agent may calculate the relative position according to content focus position, selection position, or viewport position, depending on how the user has been browsing. The user agent may indicate the proportion of content viewed in a number of ways, including as a percentage, as a relative size in bytes, etc. For two-dimensional renderings, relative position includes both vertical and horizontal positions. Techniques: + Provide a scrollbar for the viewport. Some specifications address scrolling requirements or suggestions explicitly, such as for the THEAD and TBODY elements of HTML 4.01 ([HTML4], section 11.2.3) and the 'overflow' property of CSS 2 ([CSS2], section 11.1.1). + Indicate the size of the document, so that users may decide whether to download for offline viewing. For example, the playing time of an audio file could be stated in terms of hours, minutes, and seconds. The size of a primarily text-based Web page might be stated in both kilobytes and screens, where a screen of information is calculated based on the current dimensions of the viewport. + Indicate the number of screens of information, based on the current dimensions of the viewport (e.g., "screen 4 of 10"). + Use a variable pitch audio signal to indicate the viewport's different positions. + Provide standard markers for specific percentages through the document. + Provide markers for positions relative to some position - a user selected point, the bottom, the H1, etc. + Put a marker on the scrollbar, or a highlight at the bottom of the page while scrolling (so you can see what was the bottom before you started scrolling. __________________________________________________________ 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] (Checkpoint 10.1) Techniques: + Refer to input configuration techniques. __________________________________________________________ 10.2 Avoid default input configurations that interfere with operating system accessibility conventions. [Priority 1] (Checkpoint 10.2) Note: In particular, default configurations should not interfere with operating conventions for keyboard accessibility. Information about operating system accessibility conventions is available in the Techniques document [UAAG10-TECHS]. Refer also to checkpoint 5.8. Techniques: + The default configuration should not include "Alt-F4", "Control-Alt-Delete", or other combinations that have reserved meanings on a given operating system. + Clearly document any default configurations that depart from system conventions. + Some reserved keyboard bindings are listed in the appendix on accessibility features of some operating systems. __________________________________________________________ 10.3 Provide information to the user about current author-specified input configurations (e.g., keyboard bindings specified in HTML documents with the "accesskey" attribute). [Priority 2] (Checkpoint 10.3) Techniques: + Refer to input configuration techniques. + Provide information about which keys activate form controls. __________________________________________________________ 10.4 Allow the user to change the default input configuration as follows: Allow the user to override any binding that is part of the user agent default input configuration (checkpoint 10.8). The user agent is not required to allow the user to override standard bindings for the operating system (e.g., for access to help). For any binding in the default keyboard configuration, allow the user to override it with a binding of a single key alone or with modifier keys. [Priority 2] (Checkpoint 10.4) Note: This checkpoint applies to all input methods: keyboard, voice, graphical user interface, etc. The override requirement only applies to bindings for the same input method (i.e., the user must be able to override a keyboard binding with another keyboard binding). Refer also to checkpoint 10.5, checkpoint 10.9, checkpoint 10.8, and checkpoint 11.3. Techniques: + Refer to input configuration techniques. + Allow users to restore easily the default input configuration. + Test the default keyboard configuration for usability. Ask users with different disabilities and combinations of disabilities to test configurations. + When using a physical keyboard, some users require single-key access (refer to checkpoint 10.5), others require that keys activated in combination be physically close together, while others require that they be spaced physically far apart. + Allow users to select from among pre-packaged configurations, to override some of the chosen configuration, and to save it as a profile. Not only will the user save time configuring the user agent, but this will reduce questions to technical support personnel. + Allow users to create macros and bind them to key strokes or other input methods. + Consider distance between keys and key alignment (e.g., "9/I/K", which align almost vertically on many keyboards) in the default configuration. For instance, if Enter is used to active links, put other link navigation commands near it (e.g., page up/down, arrow keys, etc. on many keyboards). In configurations for users with reduced mobility, pair related functionalities on the keyboard (e.g., left and right arrows for forward and back navigation). + Allow users to accomplish tasks through repeated key strokes (e.g., sequential navigation) since this means less physical repositioning for all users. However, repeated key strokes may not be efficient for some tasks. For instance, do not require the user to position the pointing device by pressing the "down arrow" key repeatedly. + So that users do not mistakenly activate certain functionalities, make certain combinations "more difficult" to invoke (e.g., users are not likely to press Control-Alt-Delete accidentally). __________________________________________________________ 10.5 Allow the user to override the default keyboard configuration as follows: Allow the user to override any binding that is part of the user agent default keyboard configuration (checkpoint 10.8). The user agent is not required to allow the user to override standard keyboard bindings for the operating system (e.g., for access to help). Allow the user to assign a single key binding to at least a majority of the functionalities available in the default keyboard configuration. [Priority 2] (Checkpoint 10.5) Note: This checkpoint applies to the keyboard only and always applies on systems with a standard keyboard API. In some modes of interaction (e.g., when the user is entering text), the number of available single keys will be significantly reduced. The number of available single keys will also be determined by the keyboard device capabilities. This checkpoint is an important special case of checkpoint 10.4. Refer also to checkpoint 1.3, checkpoint 10.9, checkpoint 10.8, and checkpoint 11.3. Techniques: + Refer to input configuration techniques. + Opera [OPERA] includes a mode in which users can access important user agent functionalities with single strokes from the numeric keypad. + Mouse Keys (available on some operating systems) allow users to simulate the mouse through the keyboard. They provide a usable command structure without interfering with the user interface for users who do not require keyboard-only and single-key access. __________________________________________________________ 10.6 Follow operating system conventions to indicate the input configuration. [Priority 2] (Checkpoint 10.6) Note: For example, on some operating systems, developers may specify which command sequence will activate a functionality so that the standard user interface components display that binding. For example, if a functionality is available from a menu, the letter of the activating key will be underlined in the menu. This checkpoint is an important special case of checkpoint 5.8. Techniques: + Refer to input configuration techniques. + Use system conventions to indicate the current configuration (e.g., in menus, indicate what key strokes will activate the functionality, underline single keys that will work in conjunction with a trigger key such as Alt, etc.) These are conventions used by the Sun Java Foundations Classes [JAVA-TUT] and Microsoft Foundations Classes for Windows. + Ensure that information about changes to the input configuration is available in a device-independent manner (e.g., through visual and audio cues, and through text). + If the currently active configuration changes locally (e.g., a search prompt opens, changing the keyboard mapping for the duration of the prompt), alert the user. + Named configurations are easier to remember. This is especially important for people with certain types of cognitive disabilities. For example, if the invocation of a search prompt changes the input configuration, the user may remember more easily which key strokes are active in search mode if alerted that there is a "Search Mode". Context-sensitive help (if available) should reflect the change in mode, and a list of keybindings for the current mode should be readily available to the user. __________________________________________________________ 10.7 For the configuration requirements of this document, allow the user to save user preferences in at least one user profile. Allow users to select from among available profiles or no profile (i.e., the user agent default settings). [Priority 2] (Checkpoint 10.7) Note: The configuration requirements of the checkpoints in this document involve user preferences for styles, presentation rates, input configurations, navigation, viewport behavior, and user agent notification. Techniques: + Follow applicable operating system conventions for input configuration profiles. + Allow users to choose a different profile, to switch rapidly between profiles, and to return to the default input configuration. __________________________________________________________ 10.8 Ensure that the default input configuration includes bindings for the following functionalities required by other checkpoints in this document: move focus to next active element; move focus to previous active element; activate focused link; search for text; search again for same text; next history state (forward); previous history state (back); increase size of rendered text; decrease size of rendered text; increase global volume; decrease global volume; (each of) stop, pause, resume, fast advance, and fast reverse selected audio, video, and animation. If the user agent implements the following functionalities, the default input configuration must also include bindings for them: enter URI for new resource; add to favorites (i.e., bookmarked resources); view favorites; stop loading resource; reload resource; refresh rendering; forward one viewport; back one viewport; next line; previous line. [Priority 2] (Checkpoint 10.8) Techniques: + Provide different input configuration profiles (e.g., one keyboard profile with key combinations close together and another with key combinations far apart). + Provide convenient bindings for controlling the user interface, such as showing, hiding, moving, and resizing graphical viewports. + Allow the user to configure how much the viewport should move when scrolling the viewport backward or forward through content (e.g., for a graphical viewport, "page down" causes the viewport to move half the height of the viewport, or the full height, or twice the height, etc.). + Input configurations should allow quick and direct navigation that does not rely on graphical output. Do not require the user to navigate through a graphical user interface as the only way to activate a functionality. + Offer a mode that makes the input configuration compatible with other versions of the software (or with other software). + Refer also to checkpoint 10.6. __________________________________________________________ 10.9 For graphical user interfaces, allow the user to configure the position of controls on tool bars of the user agent user interface, to select or remove controls for the user interface from a predefined set, and to restore the default user interface. [Priority 3] (Checkpoint 10.9) Note: This checkpoint is an important special case of checkpoint 10.4. Techniques: + Allow multiple icon sizes (big, small, other sizes). + Allow the user to choose icons and/or text. + Allow the user to change the grouping of icons. + Allow the user to show and hide controls. This benefits users with cognitive disabilities and users who navigate user interface controls sequentially. + Allow the user to change the position of control bars, icons, etc. Do not rely solely on drag-and-drop for reordering tool bar. Allow the user to configure the user agent user interface in a device-independent manner (e.g., through a text-based profile). __________________________________________________________ Guideline 11. Provide accessible product documentation and help. Checkpoints for accessible documentation: 11.1 Provide a version of the product documentation that conforms to at least Level Double-A of the Web Content Accessibility Guidelines 1.0 [WCAG10]. [Priority 1] (Checkpoint 11.1) Note: User agents may provide documentation in many formats, but at least one must conform to at least Level Double-A of the Web Content Accessibility Guidelines 1.0 [WCAG10]. Techniques: + Distribute accessible documentation over the Web, on CD-ROM, or by telephone. Alternative hardcopy formats may also benefit some users. + Documentation includes information bundled with a product when it is released as well as information made available subsequently (e.g., bug fixes, etc.). + Web-based support and/or documentation that is produced or maintained by the manufacturer of a user agent or by a sub-contractor of the user agent's developer must conform to the Web Content Accessibility Guidelines 1.0 [WCAG10]. In particular: 1. Provide text equivalents of all non-text content (e.g., graphics, audio-only presentations, etc.); 2. Provide extended descriptions of screen-shots, flow charts, etc.; 3. Provide a text equivalent for audio user agent tutorials. Tutorials that use speech to guide a user through the operation of the user agent should also be available at the same time as graphical representations. 4. Use clear and consistent navigation and search mechanisms; 5. Use the NOFRAMES element when the support/documentation is presented in a FRAMESET; 6. Refer also to checkpoint 11.3. + Describe the user interface with device-independent terms. For example, use "select" instead of "click on". + Provide documentation in small chunks (for rapid downloads) and also as a single source (for easy download and/or printing). A single source might be a single HTML file or a compressed archive of several HTML documents and included images. + Ensure that run-time help and any Web-based help or support information is accessible and may be operated with a single, well-documented, input command (e.g., key stroke). Use operating system conventions for input configurations related to run-time help. + Provide documentation in alternative formats such as Braille (refer to "Braille Formats: Principles of Print to Braille Transcription 1997" [BRAILLEFORMATS]), large print, or audio tape. Agencies such as Recording for the Blind and Dyslexic [RFBD] and the National Braille Press [NBP] can create alternative formats. + Provide accessible documentation for all audiences: end users, developers, etc. For instance, developers with disabilities may wish to add accessibility features to the user agent, and so require information on available APIs and other implementation details. + Ensure that product identification codes are accessible to users so they may install their software. Codes printed on product cases will not be accessible to people with visual disabilities. __________________________________________________________ 11.2 Document all user agent features that promote accessibility. [Priority 1] (Checkpoint 11.2) Note: For example, review the documentation or help system to ensure that it includes information about the accessibility requirements of WAI Guidelines. Techniques: + Refer also to techniques for checkpoint 11.4. + Provide a sensible index to accessibility features. For instance, users should be able to find "How to turn off blinking text" in the documentation (and the user interface). The user agent may implement this feature by turning off scripts, but users should not have to guess (or know) that turning off scripts will turn off blinking text. + Document configurable features in addition to defaults for those features. + Document the features implemented to conform with these guidelines. + Include references to accessibility features in both the table of contents and index of the documentation. __________________________________________________________ 11.3 Document the default input configuration (e.g., default keyboard bindings). [Priority 1] (Checkpoint 11.3) Techniques: The following table shows how one might document keyboard bindings. It shows the default keyboard configuration for versions of Netscape Navigator [NAVIGATOR] running on the Macintosh, Unix, and Windows operating systems. If a function exists in the browser but does not have a binding, its corresponding cell is marked with an asterisk. If the function does not exist, it is left blank. Note: This table lists some, but not all, functionalities and keyboard bindings of Navigator. It is meant to illustrate, not serve as definitive documentation for Netscape Navigator. Some entries contain links to special notes. The number in parentheses following the link is the number of the relevant note. Note: To make this table accessible, a linear version of Navigator Keyboard Bindings is available. CAPTION: Navigator Keyboard Bindings Function Macintosh (v 4.61) Unix (v 4.51) Windows (v 4.7) Move within a document Scroll to next page Page Down Page Down Page Down Scroll to previous page Page Up Page Up Page Up Scroll to top * * Control-Home Scroll to bottom * * Control-End Move between documents Open a new document Command+L Alt+O Control+O Stop loading a document Command+. Esc Esc Refresh a document Command+R Alt+R Control+R Load previous document Command+[ or Command+Left Arrow Alt+Left Arrow Alt+Left Arrow Load next document Command+] or Command+Right Arrow Alt+Right Arrow Alt+Right Arrow Navigate elements within a document Move focus to next frame * * * Move focus to previous frame * * * Move focus to next active element (1) Tab Tab Tab Move focus to previous active element (1) Shift+Tab Shift+Tab Shift+Tab Find word in page Command+F Alt+F Control+F Act on HTML elements Select a link * * Enter Toggle a check box * * Shift or Enter Activate radio button * * Shift Move focus to next item in an option box * * Down Arrow or Right Arrow Move focus to previous item in an option box * * Up Arrow or Left Arrow Select item in an option box * * Enter Press a button (2) Return, Space Enter, Space Enter, Space Navigate menus Activate menu * * Alt+ the underlined letter in the menu title Deactivate menu * Esc Esc Move focus to next menu item * * (3) Down Arrow Move focus to previous menu item * * (3) Up Arrow Select menu item * underlined letter in the menu item Enter Move focus to submenu * * (3) Right Arrow Move focus to main menu * * (3) Left Arrow Navigate bookmarks View bookmarks menu * (4) * Alt+C+B Move focus to next item in bookmarks menu Down Arrow (4) * Down Arrow Move focus to previous item in bookmarks menu Up Arrow (4) * Up Arrow Select item in bookmarks menu Return (4) * Enter Add bookmark Command+D Alt+K Control+D Edit bookmarks Command+B Alt+B Control+B Delete current bookmark (5) Delete Alt+D Delete Navigate history list View history list Command+H Alt+H Control+H Move focus to next item in history list * * Down Arrow Move focus to previous item in history list * * Up Arrow Move focus to first item in history list * * Left Arrow Select item in history list * * Enter (6) Close history list Command+W Alt+W Control+W Define view Increase font size (7) Shift+Command+] Alt+] Control+] Decrease font size (7) Shift+Command+[ Alt+[ Control+[ Change font color * * * Change background color * * * Turn off author-defined style sheets * * * Turn on user-defined style sheets (8) ? ? ? Apply next user-defined style sheet ? ? ? Apply previous user-defined style sheet ? ? ? Other functionalities Access to documentation * * * Notes. 1. In Windows, active elements of the user interface include links, text entry boxes, buttons, checkboxes, radio buttons, etc. In Unix and Macintosh, Tab cycles through text entry boxes only. 2. In Windows, this works for any button, since any button can gain the user interface focus using keyboard commands. In Unix and Macintosh, this only applies to the "Submit" button following a text entry. 3. In Unix, the menus cannot be opened with binding keys. However, once a menu is opened it stays opened until it is explicitly closed, which means that the menus can still be used with shortcut keys to some extent. Sometimes left and right arrows move between menus and up and down arrows move within menus, but this does not seem to work consistently, even within a single session. 4. In Macintosh, you cannot explicitly view the bookmarks menu. However, if you choose "Edit Bookmarks", which does have a keyboard binding, you can then navigate through the bookmarks and open bookmarked documents in the current window. 5. To delete a bookmark you must first choose "Edit Bookmarks" and then move the focus to the bookmark you want to delete. 6. In Windows, when you open a link from the history menu using Enter, the document opens in a new window. 7. All three systems have menu items (and corresponding shortcut keys) meant to allow the user to change the font size. However, the menu items are consistently inactive in both Macintosh and Unix. The user seems to be able to actually change the font sizes only in Windows. 8. It is important to allow users to set their own Cascading Style Sheets. Although Navigator does currently allow the user to override the author's choice of foreground color, background color, font, and font size, it does not allow some of the advanced capabilities that make CSS so powerful. For example, a blind user may want to save a series of style sheets which show only headings, only links, etc., and then view the same page using some or all of these style sheets in order to orient himself to the organization of the page before reading the page. __________________________________________________________ 11.4 In a dedicated section of the documentation, describe all features of the user agent that promote accessibility. [Priority 2] (Checkpoint 11.4) Note: This is a more specific requirement than checkpoint 11.2. Techniques: + Integrate information about accessibility features throughout the documentation. The dedicated section on accessibility should provide access to the documentation as a whole rather than standing alone as an independent section. For instance, in a hypertext-based help system, the section on accessibility may link to pertinent topics elsewhere in the documentation. + Ensure that the section on accessibility features is easy to find. __________________________________________________________ 11.5 In each software release, document all changes that affect accessibility. [Priority 2] (Checkpoint 11.5) Note: Features that affect accessibility are listed in this document and in platform-specific accessibility guidelines. Techniques: + At a minimum provide a text description of changes (e.g., in a README file). + In particular, document changes to the user interface. __________________________________________________________ 3 Accessibility topics This section presents general accessibility techniques that may apply to more than one checkpoint. 3.1 Access to content User agents must ensure that users have access to content, either rendered through the user interface or made available to assistive technologies through an API. While providing serial access to a stream of content would satisfy this requirement, this would be analogous to offering recorded music on a cassette: other technologies exist (e.g., CD-ROMs) that allow direct access to music. It is just as important for user agents to allow users to access Web content efficiently, whether the content is being rendered as a two-dimensional graphical layout, an audio stream, or a line-by-line Braille stream. Providing efficient access to content involves: * Preserving structure when rendering * Allowing the user to select specific content and query its structure or context * Providing access to equivalent alternatives of content. * Using and generating metadata to provide context These topics are addressed below. 3.1.1 Preserve and provide structure When used properly, markup languages structure content in ways that allow user agents to communicate that structure across different renderings. A table describes relationships among cells and headers. Graphically, user agents generally render tables as a two-dimensional grid. However, serial renderings (e.g., speech and Braille) must also make those relationships apparent, otherwise users will not understand the purpose of the table and the relationships among its cells (refer to the section on table techniques). User agents must render content in ways that allow users to understand the underlying document structure, which may consist of headings, lists, tables, synchronized multimedia, link relationships, etc. Providing alternative renderings (e.g., an outline view) will also help users understand document structure. Note: Even though the structure of a language like HTML is defined by a Document Type Definition (DTD), user agents may convey structure according to a "more intelligent" document model when that model is well-known. For instance, in the HTML DTD, heading elements (H1 - H6) do not nest, but presenting the document as nested headings may convey the document's structure more effectively than as a flat list of headers. 3.1.2 Allow access to selected content The guidelines emphasize the importance of navigation as a way to provide efficient access to content. Navigation allows users to access content more quickly and when used in conjunction with selection and focus mechanisms, allows users to query content for metadata. For instance, blind users often navigate a document by skipping from link to link, deciding whether to follow each link based on metadata about the link. User agents can help them decide whether to follow a link by allowing them to query each focused link for the link text, title information, information about whether the link has been visited, whether the link involves a fee, etc. While much of this information may be rendered, the information must also be available to assistive technologies. For example, the Amaya browser/editor [AMAYA] makes available all attributes and their values to the user through a context menu. The user selects an element (e.g., with the mouse) and opens an attribute menu that shows which attributes are available for the element and which are set. The user may read or write values to attributes (since Amaya is an editor). Information about attributes is also available through Amaya's structured view, which renders the document tree as structured text. The selection may be widened (moved to the nearest node one level up the document tree) by pressing the Escape key; this is a form of structured navigation based on the underlying document object model. Users may want to select content based on structure alone (as offered by Amaya) but also based on how the content has been rendered. For instance, most user agents allow users to select ranges of text content that may cross "element boundaries". 3.1.3 Access to equivalent alternatives of content Authors provide equivalent alternatives to content so that users may understand the function of a page or part of a page even though they may not be able to make use of a particular content type. For example, authors must provide text equivalents for non-text content (e.g., images, video, audio-only presentations, etc.) because text may be rendered as speech or Braille and may be used by users with visual or hearing or both disabilities. User agents must ensure that these alternatives are available to users, either through the user interface or through an API. How authors specify equivalent alternatives depends on the markup language used. For information about equivalent alternatives for SMIL [SMIL] content, refer to "Accessibility Features of SMIL" [SMIL-ACCESS]. In HTML 4.01 [HTML4], authors specify equivalent alternatives for content as follows: * For the IMG element (section 13.2): the "alt" (section 13.8), "title" (section 7.4.3), and "longdesc" (section 13.2) attributes. Refer to the section on long descriptions. * For the OBJECT element (section 13.3): the content of the element and the "title" attribute. * For the deprecated APPLET element (section 13.4): the "alt" attribute and the content of the element. * For the AREA element (section 13.6.1): the "alt" attribute. * For the INPUT element (section 17.4): the "alt" attribute. * For the ACRONYM and ABBR elements (section 9.2.1): the "title" attribute (for acronym or abbreviation expansion). * For the TABLE element (section 11.2.1): the "summary" attribute. * For frames: the NOFRAMES element (section 16.4.1) and the "longdesc" attribute (section 16.2.2) on FRAME and IFRAME (section 16.5). * For scripts: the NOSCRIPT element (section 18.3.1). Techniques for providing access to equivalent alternatives include the following: * Make information available with different levels of detail. For example, for a voice browser, offer two options for equivalent alternatives to HTML images: 1. Speak only "alt" text by default, but allow the user to hear "longdesc" text on an image by image basis. 2. Speak "alt" text and "longdesc" for all images. * Allow the user to configure how the user agent renders a long description (e.g., "longdesc" in HTML 4.01 [HTML4]). Some possibilities include: 1. Render the long description in a separate view. 2. Render the long description in place of the associated element. 3. Do not render the long description, but allow the user to query whether an element has an associated long description (e.g., with a context-sensitive menu) and provide access to it. 4. Use an icon (with a text equivalent) to indicate the presence of a long description. 5. Use an audio cue to indicate the presence of a long description when the user navigates to the element. * For an object (e.g., an image) with an author-specified geometry that the user agent does not render, allow the user to configure how the equivalent alternative should be rendered. For example, within the specified geometry, by ignoring the specified geometry altogether, etc. * For multimedia presentations with several alternative tracks, ensure access to all tracks and allow the user to select individual tracks. The Quicktime player [QUICKTIME] allows users to turn on and off any number of tracks separately. * For multimedia presentations with several alternative tracks, allow users to select tracks based on natural language preferences. SMIL 1.0 [SMIL] allows users to specify captions in different natural languages. By setting language preferences in the SMIL player (e.g., the G2 player [G2]), users may access captions (or audio) in different languages. Allow users to specify different languages for different content types (e.g., English audio and Spanish captions). * For missing equivalent alternatives of content: + The "Altifier Tool" [ALTIFIER] illustrates smart techniques for generating text equivalents (for images, etc.) when the author has not specified any. + If no captioning information is available and captioning is turned on, render "no captioning information available" in the captioning region of the viewport. 3.1.4 Context Authors and user agents provide context to users through content, structure, navigation mechanisms, and query mechanisms. Titles, dimensions, dates, relationships, the number of elements, and other metadata all help orient the user, particularly when available as text. For instance, user agents can help orient users by allowing them to request that document headings and lists be numbered. Refer also to the section on table techniques, which explains how users agents can offer table navigation and the ability to query a table cell for information about the cell's row and column position, associated header information, etc. * User agents can use style sheet languages such as CSS 2 [CSS2] and XSLT [XSLT] to generate context information (refer to techniques for generated content). * For information about elements and attributes that convey metadata in HTML, refer to the index of elements and attributes in "Techniques for Web Content Accessibility Guidelines 1.0" [WCAG10-TECHS]. * For information about elements and attributes that convey metadata in SMIL, refer to the index of attributes in the W3C Note "Accessibility Features of SMIL" [SMIL-ACCESS]. * Describe a selected element's position within larger structures (e.g., numerical or relative position in a document, table, list, etc.). For example: tenth link of fifty links; document heading 3.4; list one of two, item 4.5; third table, three rows and four columns; current cell in third row, fourth column; etc. Allow users to get this information on demand (e.g., through a keyboard shortcut). Provide this information on the status line on demand from the user. 3.2 User control of style To ensure accessibility, users must be able to configure the style of rendered content and the user interface. Author-specified styles, while important, may make content inaccessible to some users. User agents must allow users to increase the size of text (e.g., with a zoom mechanism or font size control), to change colors and color combinations, to slow down multimedia presentations, etc. To give authors design flexibility and allow users to control important aspects of content style, user agents should implement CSS ([CSS1], [CSS2]) and allow users to create and apply user style sheets. CSS includes mechanisms for tailoring rendering for a particular output medium, including audio, Braille, screen, and print. * User agents should implement the cascade order of CSS 2 ([CSS2], section 6.4.1) not CSS 1. In CSS 2, user style sheets with "!important" declarations (section 6.4.2) take precedence over author styles. Refer also to Web Content Accessibility Guidelines 1.0 checkpoint 3.3 [WCAG10]. * CSS-enabled user agents should consider as part of the cascade the markup used for style, giving it a lower weight than actual style sheets. This allows authors to specify style through markup for older user agents and to use more powerful style sheets for CSS-enabled user agents. Refer to the section on the precedence of non-CSS presentational hints in CSS 2 ([CSS2], section 6.4.4). * To hide the CSS syntax from the user, user agents may implement user style sheets through the user agent user interface. User agents can generate a user style sheet from user preferences or behave as though it did. Amaya [AMAYA] provides a GUI-based interface to create and apply internal style sheets. The same technique may be used to control a user style sheet. * For animations, allow users to control the rate of animation, to pause and play animations, to step through the animation, and to play it at the specified rate. * Allow the user to pause a video presentation, to move, resize, and position tracks that appear on the screen (including captions, subtitles and signed translations) and to apply CSS stylesheets to text-based presentation. * In the user interface: + Allow the user to select large or small buttons and controls. Ensure that these values are applied consistently across the user interface. + Allow the user to regroup buttons and controls, and reorder menus. + Use standard operating system controls for allowing configuration of font sizes, speech rates, and other style parameters. 3.3 Link techniques User agents make links accessible by providing navigation to links, helping users decide whether to follow them, and allowing interaction in a device-independent manner. Link techniques include the following: * Refer to sequential navigation techniques for information about navigating to links. * Provide a link view that lists all links in the document. Allow the user to configure how the links are sorted (e.g., by document order, sequential navigation order, alphabetical order, visited or unvisited or both, internal or external or both, etc.). * Help the user remember links by including metadata in the link view. For example, identify a selected link as "Link X of Y", where "Y" is the total number of links. Lynx [LYNX] numbers each link and provides information about the relative position in the document. Position is relative to the current page and the number of the current page out of all pages. Each page usually has 24 lines. * Allow the user to configure how much information about a link to present in the content view (when a link receives focus). For instance, allow the user to choose between "Display links using hyperlink text" or "Display links by title (if present)", with an option to toggle between the two views. For a link without a title, use the link text. * For links with non-text content such as images, make available a text equivalent as follows: 1. If the author has specified a non-empty text equivalent for the image (e.g., "alt" in HTML), use that as the link text; 2. Otherwise, use the link title if available; 3. Otherwise, use title information of the designated Web resource (e.g., the TITLE element of HTML for links to HTML documents). 4. Otherwise, render part of the filename or URI of the designated Web resource. 5. Otherwise, insert a generic placeholder (e.g., [LINK]) in place of the image. * For an image in link content, ensure that the user has access to the link and any long description associated with the image. * Ensure that all information about a link is available in a device-independent manner. For example, do not rely solely on fonts or colors to alert the user whether or not the link has previously been followed. Allow the user to configure how information will be presented (colors, sounds, status bar messages, some combination, etc.). * If the user activates a broken link, leave the viewport where it is and alert the user (e.g., in the status bar and with a graphical or audio alert). Moving the viewport suggests that a link is not broken, which may disorient the user. * If the focus is used to select active elements, implement the ':hover', ':active', and ':focus' pseudo-classes of CSS 2 ([CSS2], section 5.11.3). This allows users to modify content focus presentation with user style sheets. Use them in conjunction with the CSS 2 ':before' pseudo-elements ([CSS2], section 5.12.3) to clearly indicate that something is a link (e.g., 'A:before { content : "LINK:" }'). Refer also to techniques for generated content. * Do not mark all local links (to anchors in the same page) as visited when the page has been visited. JAWS for Windows HTML Options menu, which allows configuration of a number of link rendering options As shown in the following image, JAWS for Windows [JFW] offers a view for configuring a number of rendering features, notably some concerning link types, text link verbosity, image map link verbosity, graphical link verbosity, and internal links. 3.4 List techniques User agents can make lists accessible by ensuring that list structure - and in particular, embedded list structure - is available through navigation and rendering. * Allow users to turn on "contextual" rendering of lists (even for unordered "bullet" lists). Use compound numbers (or letters, numbers, etc.) to introduce each list item (e.g., "1, 1.1, 1.2, 1.2.1, 1.3, 2, 2.1"). This provides more context and does not rely on the information conveyed by a graphical rendering, as in: 1. 1. 2. 1. 3. 2. 1. which might be serialized for speech or Braille as "1, 1, 2, 1, 2, 3, 2, 1". * Specify list numbering styles in CSS. Refer to the section generated content, automatic numbering, and lists in CSS ([CSS2], section 12). Example. The following CSS 2 style sheet (taken from CSS 2, section 12.5) shows how to specify compound numbers for nested lists created with either UL or OL elements. Items are numbered as "1", "1.1", "1.1.1", etc. End example. 3.5 Table techniques The HTML TABLE element was designed represent relationships among data ("data" tables). Even when authored well and used according to specification, tables may pose problems for users with disabilities for a number of reasons: * Users who access a table serially (e.g., as speech or Braille) may have difficulty grasping the relationships among cells, especially for large and complex tables. * Users who with cognitive disabilities may have trouble grasping or remembering relationships between cells and headers, especially for large and complex tables. * Users of screen magnifiers or with physical disabilities may have difficulties navigating to the desired cells of a table. For these situations, user agents may assist these users by providing table navigation mechanisms and supplying context that is present in a two-dimensional rendering (e.g., the cells surrounding a given cell). To complicate matters, many authors use tables to lay out Web content ("layout" tables). Not only are table structures used to lay out objects on the screen, table elements such as TH (table header) in HTML are used to font styling rather than to indicate a true table header. These practices make it difficult for assistive technologies to rely on markup to convey document structure. Consequently, assistive technologies often must resort to interpreting the rendered content, even though the rendered content has "lost" information encoded in the markup. For instance, when an assistive technology "reads" a table from its graphical rendering, the contents of multiline cells may become intermingled. For example, consider the following table: This is the top left cell This is the top right cell of the table. of the table. This is the bottom left This is the bottom right cell of the table. cell of the table. Screen readers that read rendered content line by line would read the table cells incorrectly as "This is the top left cell This is the top right cell". So that assistive technologies are not required to gather incomplete information from renderings, these guidelines require that user agents provide access to document source through an API (refer to checkpoint 5.3). The following sections discuss techniques for providing improved access to tables. 3.5.1 Table metadata Users of screen readers or other serial access devices cannot gather information "at a glance" about a two-dimensional table. User agents can make tables more accessible by providing the user with table metadata such as the following: * The table caption (the CAPTION element in HTML) or summary information (the "summary" attribute in HTML). * The number of column groups and columns. Note that the number of columns may change according to the row. Also, some parts of a table may have two dimensions, others three, others four, etc. Project dimensionality higher than two onto two when rendering information. * The number of row groups and rows, in particular information about table headers and footers. * Which rows contain header information (whether at the top or bottom of the table). * Which columns contain header information (whether at the left or right of the table). * Whether there are subheads. * How many rows or columns a header spans. When navigating, quick access to table metadata will allow users to decide whether to navigate within the table or skip over it. Other techniques: * Allow users to query table summary information from inside a cell. * Allow the user to choose different levels of detail for the summary (e.g., brief table summary and a more detailed summary). * Allow the user to configure navigation so that table metadata is not (re-)rendered each time the user enters the table. 3.5.2 Linear rendering of tables A linear rendering of tables -- cells presented one at a time, row by row or column by column -- may be useful, but generally only for simple tables. For more complex tables, user agents need to convey more information about relationships among cells and their headers. Note: The following techniques apply to columns as well as rows. The elements listed in this section are HTML 4.01 table elements ([HTML4], section 11). * Provide access to one row at a time, beginning with any column header. If a header is associated with more than one row, offer that header for each row concerned. * Render cells with their associated headers. Allow the user to configure how often headers are rendered (e.g., by implementing the 'speak-header' property in CSS 2 [CSS2], section 17.7.1). Note also that the "abbr" attribute in HTML 4.01 specifies abbreviated headers for speech and other rendering ([HTML4], section 11.2.6). Refer also to information about cell headers later in this section. * Provide access to cell content as marked up in the document source. * Refer to techniques for authoring accessible tables in "Techniques for Web Content Accessibility Guidelines 1.0" [WCAG10-TECHS]. 3.5.3 Cell rendering The most important aspect of rendering a table cell is that the cell's contents be rendered faithfully and be identifiable as the contents of a single cell. However, user agents may provide additional information to help orient the user: * Render the row and column position of the cell in the table. * Indicate how many rows and columns a cell spans. * Since the contents of a cell in a data table may only be comprehensible in context (i.e., with associated header information, row/column position, neighboring cell information etc.), allow users to navigate to cells and query them for this information. * For HTML tables, refer to the section on associating header information with data cells of HTML 4.01 ([HTML4], section 11.4.1). * In a table with a leading row and column of TH cells, the interpretation of the corner cell as an empty TD or TH should not contribute to the set of headings for cells in that row and column. * For nested tables, render information about the level of nesting. * Since a cell may belong to N different dimensions in a multi-dimensional table, provide information about headers from each dimension. 3.5.4 Cell header algorithm Properly constructed data tables distinguish header cells from data cells. How headers are associated with table cells depends on the markup language. The following algorithm is based on the HTML 4.01 algorithm to calculate header information ([HTML4], section 11.4.3). For the sake of brevity, it assumes a left-to-right ordering, but will work for right-to-left tables as well (refer to the "dir" attribute of HTML 4.01 [HTML4], section 8.2). For a given cell: * Search left from the cell's position to find row header (TH) cells. Then search upwards from the cell's position to find column header cells. The search in a given direction stops when the edge of the table is reached or when a data cell is found after a header cell. If no headers are found in either direction (left or up), search in the other directions (right or down). * Allow the user to configure where the header text comes from. For example, in HTML 4, either the header cell's text content or the value of the "abbr" attribute value ([HTML4], section 11.2.6). * Insert row headers into the list in the (left-to-right) order they appear in the table. Include values implicitly resulting from header cells in prior rows with rowspan="R", sufficient to extend into the current row. * Insert column headers after row headers, in the (top-to-bottom) order they appear in the table. Include values implicitly resulting from header cells in other columns with colspan="C", sufficient to extend into the current column containing the TD cell. * If a header cell has a value for the "headers" attribute, then insert it into the list and stop the search for the current direction. * Treat cells with a value for the "axis" attribute as header cells. * Be sure to take into account header cells that span several rows or columns. Not all data tables include proper header markup, which the user agent may be able to detect. Some repair strategies for finding header information include the following: * Consider that the top or bottom row contains header information. * Consider that the leftmost or rightmost column in a column group contains header information. * If cells in an edge row or column span more than one row or column, consider the following row or column to contain header information as well. * When trying to guess table structure, present several solutions to the user. Other repair issues to consider: * TH cells on both the left and right of the table need to be considered. * For TH cells with "rowspan" set: the content of those TH cells must be considered for each of the N-1 rows below the one containing that TH content. * An internal TH surrounded by TDs makes it difficult to know whether the header applies to cells to its left or right in the same row (or in both directions) or cells above or below it in the same column (or in both directions). * Finding column header cells assumes they are all above the TD cell to which they apply. * A TH with "colspan" set needs to be included in the list of THs for the N-1 columns to its right. 3.5.5 Table navigation To permit efficient access to tables, user agents should allow users to navigate to tables and within tables, to select individual cells, and to query them for information about the cell and the table as a whole. * Allow users to navigate to a table, down to one of its cells, and back up to the table level. This should work recursively for nested tables. * Allow users to navigate to a cell by its row and column position. * Allow users to navigate to all cells under a given header. * Allow users to navigate row by row or column by column. * Allow users to navigate to the cells around the current cell. * Allow users to navigate to the first or last cell of a row, column, or the table. * Allow users to navigate from a cell directly to its related headers (if it's possible to navigate to the headers). * Allow the user to search for text content within a table (i.e., without searching outside of the table). Allow the user to search for text content within specific rows or columns, row groups or column groups, or limited by associated headers. * Notify the user when the navigation reaches a table edge and when a cell contains another table. * Allow relative and direct navigation. For example, entering "-3, 20" might mean "left three cells, up 20 cells"). * Allow navigation of table headers or footers only. * Consider the issues raised by navigation to or from a cell that spans more than one row or column. * For examples of table navigation, refer to the table navigation script from the Trace Research Center [TABLENAV]. 3.6 Image map techniques One way to make an image map accessible is to render the links it contains as text links. This allows assistive technologies to render the links a speech or Braille, and benefits users with slow access to the Web and users of small Web devices that do not support images but can support hypertext. User agents may allow users to toggle back and forth between a graphical mode for image maps and a text mode. To construct a text version of an image map in HTML: * If the content of the MAP element includes links, use them. * Otherwise, for each AREA in the map, if a (non-null) text equivalent is available (the "alt" attribute), use it as the content of a generated link. * When the author has specified a null text equivalent, do not render the link. * When the author has not specified a text equivalent, render (for example) "Map area" followed by part of the URI of the link. Furthermore, user agents that render a text image map instead of an image may preface the text image map with inline metadata such as: * a string that announces the image map (e.g., "Start map") * any text equivalent associated with the image (e.g., "alt" for IMG). * the number of links in the map. Allow users to suppress, shrink, and expand text versions of image maps so that they may quickly navigate to an image map (which may be, for example, a navigation tool bar) and decide whether to "expand" it and follow the links of the map. The metadata listed above will allow users to decide whether to expand the map. Ensure that the user can expand and shrink the map and navigate its links using the keyboard and other input devices. 3.7 Frame techniques Frames were originally designed so that authors could divide up graphic real estate and allow the pieces to change independently (e.g., selecting an entry in a table of contents in one frame changes the contents of a second frame). While frames are not inherently inaccessible, they raise some accessibility issues: * Alternatives to frame content. Some users cannot make use of frames because they cannot grasp the (spatial or logical) relationships conveyed by frame layout. Others cannot use them because their user agents or assistive technology does not support them or makes access difficult (e.g., users with screen readers or screen magnifiers). * Navigation. Users must be able to navigate from frame to frame in a device independent manner. * Orientation. Users need to know what frame they are in (thus, frames must be titled), what other frames are available, and how the frames of a frameset are organized. * Dynamic changes. Users need to know how the changes they cause in one frame affect other frames. To name a frame in HTML, use the following algorithm: 1. Use the "title" attribute on FRAME, or if not present, 2. Use the "name" attribute on FRAME, or if not present, 3. Use title information of the referenced frame source (e.g., the TITLE element of the source HTML document), or 4. Use title information of the referenced long description (e.g., what "longdesc" refers to in HTML), or 5. Use frame context (e.g., "Frame 2.1.3" to indicate the path to this frame in nested framesets). To make frames accessible, user agents should do the following: * Make available the author-specified frame equivalents (e.g., provided by the HTML 4.01 NOFRAMES element ([HTML4], section 16.4.1). * Here is a technique for the case of a frameset that does not contain a NOFRAMES equivalent but the individual frames have associated long descriptions ("longdesc"): 1. For each frameset, render the frameset title as an H1 heading. 2. For each frame, render the frame title in an H2 heading, followed by the content of the associated long description. 3. Create a navigable table of contents according to the (possibly nested) frameset structure. Each entry in the table of contents should link to a frameset or frame. The end of the content used for each frame should include a link back to this table of contents. * Notify the user when the viewport contains a frameset. * Render a frameset as a list of links to named frames so the user can identify the number of frames. The list of links may be nested if framesets are nested. * Provide information about the number of frames in the frameset. * Highlight the current frameset (e.g., with a thick border, by displaying the name of the current frameset in the status bar, etc.) * Allow the user to query the current frame for metadata about the frame. Make available the frame title for speech synthesizers and Braille displays. Users may also use information about the number of images and words in the frame to guess the purpose of the frame. For example, few images and few words is probably a title, more words is probably an index, many words is probably text area. * Allow navigation between frames (forward and backward through the nested structure, return to global list of links to frames). Note: Recall that the user must be able to navigate frames through all supported input devices. * Allow navigation to frame equivalents. * Allow the user to bookmark the current frame. * Notify the user when an action in one frame causes the content of another frame to change. Allow the user to navigate quickly to the frame(s) that changed. * Authors can suppress scrolling of frames with scrolling="no". In this case, the user agent must make available content that is not in the viewport. * The user agent may ignore some attributes of the FRAME element of HTML 4.01 ([HTML4], section 16.2.2): "noresize", "scrolling", and "frameborder". Consider renderings of the following document: Time Value of Money <P>List of Presentation Slides</P> <OL> <LI><A HREF="slide001">Time Value of Money</A> <LI><A HREF="slide002">Topic Overview</A> <LI><A HREF="slide003">Terms and Short Hand</A> <LI><A HREF="slide004">Future Value of a Single CF</A> <LI><A HREF="slide005">Example 1: FV example:The NBA's new Larry Bird exception</A> <LI><A HREF="slide006">FV Example: NBA's Larry Bird Exception (cont.)</A> <LI><A HREF="slide007">SuperStar's Contract Breakdown</A> <LI><A HREF="slide008">Present Value of a Single Cash Flow</A> <LI><A HREF="slide009">Example 2: Paying Jr, and A-Rod</A> <LI><A HREF="slide010">Example 3: Finding Rate of Return or Interest Rate</A> <LI><A HREF="slide011">Annuities</A> <LI><A HREF="slide012">FV of Annuities</A> <LI><A HREF="slide013">PV of Annuities</A> <LI><A HREF="slide014">Example 4: Invest Early in an IRA</A> <LI><A HREF="slide015">Example 4 Solution</A> <LI><A HREF="slide016">Example 5: Lotto Fever </A> <LI><A HREF="slide017">Uneven Cash Flows: Example 6:Fun with the CF function</A> <LI><A HREF="slide018">Example 6 CF worksheet inputs</A> <LI><A HREF="slide019">CF inputs continued</A> <LI><A HREF="slide020">Non-Annual Interest Compounding</A> <LI><A HREF="slide021">Example 7: What rate are you really paying?</A> <LI><A HREF="slide022">Nominal to EAR Calculator</A> <LI><A HREF="slide023">Continuous Interest Compounding</A> <LI><A HREF="slide024">FV and PV with non-annual interest compounding</A> <LI><A HREF="slide025">Non-annual annuities</A> <LI><A HREF="slide026">Example 8: Finding Monthly Mortgage Payment</A> <LI><A HREF="slide027">solution to Example 8</A> </OL> The following examples show how some user agents handle this frameset. Example frameset with five frame panes rendered in Microsoft Internet Explorer 5.0 Rendering of a frameset by Internet Explorer [IE-WIN]. Rendering by Lynx [LYNX]: Time Value of Money FRAME: Size buttons FRAME: Presentation Outline FRAME: Navigation buttons FRAME: Slide Image FRAME: Notes List of Presentation Slides 1. Time Value of Money 2. Topic Overview 3. Terms and Short Hand 4. Future Value of a Single CF 5. Example 1: FV example:The NBA's new Larry Bird exception 6. FV Example: NBA's Larry Bird Exception (cont.) 7. SuperStar's Contract Breakdown 8. Present Value of a Single Cash Flow 9. Example 2: Paying Jr, and A-Rod 10. Example 3: Finding Rate of Return or Interest Rate 11. Annuities 12. FV of Annuities 13. PV of Annuities 14. Example 4: Invest Early in an IRA 15. Example 4 Solution 16. Example 5: Lotto Fever 17. Uneven Cash Flows: Example 6:Fun with the CF function 18. Example 6 CF worksheet inputs 19. CF inputs continued 20. Non-Annual Interest Compounding 21. Example 7: What rate are you really paying? 22. Nominal to EAR Calculator 23. Continuous Interest Compounding 24. FV and PV with non-annual interest compounding 25. Non-annual annuities 26. Example 8: Finding Monthly Mortgage Payment 27. solution to Example 8 Example frameset with five links for each of the frame elements in IBM home page reader Rendering of a frameset by Home Page Reader [HPR]. User agents may also indicate the number of frames in a document and which frame is the current frame via the menu bar or popup menus. Users can configure the user agent to include a FRAMES menu item in their menu bar. The menu bar makes the information highly visible to all users and is very accessible to assistive technologies. A pull down menu indicating the number of frames in a document, the labels associated with each frame, and a check mark to indicate the current frame In this image of the Accessible Web Browser [AWB], the menu bar indicates the number of frames and uses a check mark next to the name of the current frame. 3.8 Form techniques To make forms accessible, user agents need to ensure that users may interact with them in a device-independent manner, that users can navigate to the various form controls, and that information about the form and its controls is available on demand. 3.8.1 Form navigation techniques * Allow users to navigate to forms and to all controls within a form (refer also to table navigation techniques). Opera [OPERA] and Navigator [NAVIGATOR] provide such functionality in a non-interactive manner, a "form navigation" keyboard commands. When invoked, these "form navigation" commands move the user agent's current focus to the first form control (if any) in the document. * If there are no forms in a document and the user attempts to navigate to a form, alert the user. * Provide a navigable, structured view of form controls (e.g., those grouped by LEGEND or OPTGROUP in HTML) along with their labels. * For labels explicitly associated with form controls (e.g., "for" attribute on LABEL in HTML), make available label information when the user navigates among the form controls. * As the user navigates to a form control, provide information about whether the control must be activated before form submission. * Allow the user to navigate away from a menu without selecting any option (e.g., by pressing the Escape key). * As the user navigates to a form control, provide information (e.g., through context-sensitive help) about how the user can activate the control. Provide information about what is required for each form control. Lynx [LYNX] conveys this information by providing information about the currently selected form control via a status line message: + Radio Button: Use right-arrow or Return to toggle + Checkbox Field: Use right-arrow or Return to toggle + Option List: Press return and use arrow keys and return to select option + Text Entry Field: Enter Text. Use Up or Down arrows or Tab to move off + Textarea: Enter text. Up or Down arrows or Tab to move off (^Ve for editor) Note: The ^Ve (caret-V, e) command, included in the TEXTAREA status line message, enables the user to invoke an external editor defined in the local Lynx configuration file (lynx.cfg). 3.8.2 Form orientation techniques Provide the following information about forms on demand: * The number of forms in the document. * The percentage of a form that has already been filled out. This will help users with serial access to form controls know whether they have completed the form. Otherwise, users who encounter a submit button that is not the last control of the form might inadvertently submit the incomplete form. 3.8.3 Form control orientation techniques Provide the following information about the controls in a form on demand (e.g., for the control with focus): * Indicate the number of controls in the form. * Indicate the number of controls that have not yet been completed. * Provide a list of controls that must be activated before form submission. * Provide information about the order of form controls (e.g., as specified by "tabindex" in HTML). This is important since: 1. Most forms are visually oriented, employing changes in font size and color. 2. Users who access forms serially need to know they have supplied all the necessary information before submitting the form. * Provide information about which control has focus (e.g., "control X of Y for the form named "MyForm"). The form name is very important for documents that contain more than one form. This will help users with serial access to form controls know whether they have completed the form. * Allow the user to query a form control for information about title, value, grouping, type, status, and position. * When a group of radio buttons receives content focus, identify the radio button with content focus as "Radio Button X of Y", where "Y" represents the total number of radio buttons in the group. HTML 4.01 specifies the FIELDSET element ([HTML4], section 17.10), which allows authors to group thematically related controls and labels. The LEGEND element ([HTML4], section 17.10) assigns a caption to a FIELDSET. For example, the LEGEND element might identify a FIELDSET of radio buttons as "Connection Rate". Each button could have a LABEL element ([HTML4], section 17.9.1) stating a rate. When it receives content focus, identify the radio button as "Connection Rate: Radio button X of Y: 28.8kpbs", where "Y" represents the total number of radio buttons in the grouping and "28.8kbps" is the information contained in the LABEL. * Allow the user to invoke an external editor instead of editing directly in a TEXTAREA control. This allows users to use all the features of the external editor: macros, spell-checkers, validators, known input configurations, backups and local copies, etc. * Provide an option for transforming menus into checkboxes or radio buttons. In the transformation, retain the accessibility information specified by the author for the original form controls. Preserve the labels provided for the OPTGROUP and each individual OPTION, and re-associate them with the generated checkboxes. The LABEL defined for the OPTGROUP should be converted into a LEGEND for the result FIELDSET, and each checkbox should retain the LABEL defined for the corresponding OPTION. Lynx [LYNX] does this for HTML SELECT elements that have the "multiple" attribute specified. 3.8.4 Form submission techniques Some users do not want forms to be submitted without their consent. The following techniques address user control of form submissions: * Allow the user to turn off scripts, as authors may write scripts that submit a form when particular events occur (e.g., "onchange" events). Be aware of this type of practice: