Techniques for User Agent Accessibility Guidelines 1.0

Notes and rationale:

1. It is up to the user agent developer to decide which functionalities are best served by direct keyboard access and which are best served by spatial access through the keyboard (or pointing device). The UAAG 1.0 does not discourage a pointing device interface, but it does require redundancy through the keyboard. In most cases, developers can allow operation of the user agent without relying on motion "through space"; this includes text selection (a text caret may be used to establish the start and end of the selection), region selection (allow the user to describe the coordinates or position of the region, e.g., relative to the viewport), drag-and-drop (allow the user to designate start and end points and then say "go"), etc.
2. For instance, the user must be able to do the following through the keyboard alone (or pointing device alone or voice alone):
   • Select content and operate on it. For example, if the user can select rendered text with the mouse and make it the content of a new link by pushing a button, they also need to be able to do so through the keyboard and other supported devices. Other operations include cut, copy, and paste.
   • Set the focus on viewports and on enabled elements.
   • Install, configure, uninstall, and update the user agent software.
   • Use the graphical user interface menus. Some users may wish to user the graphical user interface even if they cannot use or do not wish to use the pointing device.
   • Fill out forms.
   • Access documentation.
3. Suppose a user agent does not allow complete operation through the keyboard alone. It is still possible to claim conformance for the user agent in conjunction with a special module designed to "fill in the gap".

Who benefits:

1. Users with blindness are most likely to benefit from direct access through the keyboard, including navigation of user interface controls; this is a logical navigation, not a spatial navigation.
2. Users with physical disabilities are most likely to benefit from a combination of direct access and spatial access through the keyboard. For some users with physical disabilities, moving the pointing device through a physical mouse may be significantly more difficult than moving the pointing device with arrow keys, for example.
3. This checkpoint will also benefit users of many other alternative input devices (which make use of the keyboard API) and also anyone without a mouse.
4. While keyboard operation is expected to improve access for many users, operation by keyboard shortcuts alone may reduce accessibility (and usability) by requiring users to memorize a long list of shortcuts. Developers should provide mechanisms for contextual access to user agent functionalities (including keyboard-operable cascading mechanisms, context-sensitive help, keyboard operable configuration tabs, etc.) as well as direct access to those functionalities. See also checkpoint 11.5.

Notes and rationale:

1. For example, users without a pointing device need to be able to activate form controls and links (including the links in a client-side image map).
2. Events triggered by a particular device generally follow a set pattern, and often in pairs: start/end, down/up, in/out. One would not expect a "key down" event for a given key to be followed by another "key down" event without an intervening "key up" event.

Who benefits:

1. Users with blindness or some users with a physical disability, and anyone without a pointing device.

Example techniques:

1. To preserve the expected order of events, provide a dynamically changing menu of available handlers. For example, an initial menu of handlers might only allow the user to trigger a "mousedown" event. Once triggered, the menu would not allow "mousedown" but would allow "mouseup" and "mouseover", etc.
2. For example, in HTML 4 [HTML4], input device event handlers are described in section 18.2.3. They are: onclick, ondblclick, onmousedown, onmouseover, onmouseout, onfocus, onblur, onkeypress, onkeydown, and onkeyup.
3. In "Document Object Model (DOM) Level 2 Events Specification" [DOM2EVENTS], focus and activation types are discussed in section 1.6.1. They are: DOMFocusIn, DOMFocusOut, and DOMActivate. These events are specified independent of a particular input device type.
4. In "Document Object Model (DOM) Level 2 Events Specification" [DOM2EVENTS], mouse event types are discussed in section 1.6.2. They are: click, mousedown, mouseup, mouseover, mousemove and mouseout.
5. The DOM Level 2 Event specification does not provide a key event module.
6. Sequential technique: Add each input device event handler to the serial navigation order (refer to checkpoint 9.3). Alert the user when the user has navigated to an event handler, and allow activation. For example, an link that also has a onMouseOver and onMouseOut event handlers defined, might generate three "stops" in the navigation order: one for the link and two for the event handlers. If this technique is used, allow configuration so that input device event handlers are not inserted in the navigation order.
7. Query technique: Allow the user to query the element with content focus for a menu of input device event handlers.
8. Descriptive information about handlers can allow assistive technologies to choose the most important functions for activation. This is possible in the Java Accessibility API [JAVAAPI], which provides an an AccessibleAction Java interface. This interface provides a list of actions and descriptions that enable selective activation. See also checkpoint 6.3.
9. Using MSAA [MSAA] on the Windows platform:
   • Retrieve the node in the document object that has current focus.
   • Call the IHTMLDocument4::fireEvent method on that node.

Related techniques:

1. See image map techniques.

References:

1. For example, section 16.5 of the SVG 1.0 Candidate Recommendation [SVG] specifies processing order for user interface events.

Notes and rationale:

1. User agents should use modality-specific messages in the user interface (e.g., graphical scroll bars, beeps, and flashes) as long as redundant mechanisms are available or possible. These redundant mechanisms will benefit all users, not just users with disabilities.

Who benefits:

1. Users with blindness, deafness, or who are hard of hearing. Mechanisms that are redundant to audio will benefit 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.

Example techniques:

1. Render text messages on the status bar of the graphical user interface. Allow users to query the viewport for this status information (in addition to having access through graphical rendering).
2. Make available information in a manner that allows other software to present it according to the user's preferences. For instance, if the graphical user agent uses proportional scroll bars to indicate the position of the viewport in content, make available this same information in text form. For instance, this will allow other software to render the proportion of content viewed as synthesized speech or as braille.

Doing more:

1. Allow configuration to render or not render status information (e.g., allow the user to hide the status bar).

Notes and rationale:

1. The right to disregard only applies when the rendering requirement of another specification contradicts the requirements of the current document; no exemption is granted if the other specification is consistent with or silent about a requirement made by the current document.

Who benefits:

1. Users with disabilities when specifications include features that promote accessibility (e.g., scalable graphics benefit users with low vision, style sheets allow users to override author and user style sheets).

Example techniques:

1. Provide access to attribute values (one at a time, not as a group). For instance, allow the user to select an element and read values for all attributes set for that element. For many attributes, this type of inspection should be significantly more usable than a view of the text source.
2. When content changes dynamically (e.g., due to embedded scripts or content refresh), users need to have access to the content before and after the change.
3. Make available information about abbreviation and acronym expansions. For instance, in HTML, look for abbreviations specified by the ABBR and ACRONYM elements. The expansion may be given with the "title" attribute (refer to the Web Content Accessibility Guidelines 1.0 [WCAG10], checkpoint 4.2). To provide expansion information, user agents may:
   • Allow the user to configure that the expansions be used in place of the abbreviations,
   • Provide a list of all abbreviations in the document, with their expansions (a generated glossary of sorts)
   • Generate a link from an abbreviation to its expansion.
   • Allow the user to query the expansion of a selected or input abbreviation.
   • If an acronym has no expansion in one location, look for another occurrence in content that does. User agents may also look for possible expansions (e.g., in parentheses) in surrounding context, though that is a less reliable technique.

Related techniques:

1. See the sections on access to content, link techniques, table techniques, frame techniques, and form techniques.

Doing more:

1. If the requirements of the current document contradict the rendering requirements of another specification, the user agent may offer a configuration to allow conformance to one or the other specification.

References:

1. Sections 10.4 ("Client Error 4xx") and 10.5 ("Server Error 5xx") of the HTTP/1.1 specification [RFC2616] 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.

Notes and rationale:

1. In general, user agent developers should not rely on a "source view" to convey information to users, most of whom are not familiar with markup languages. A source view is still important as a "last resort" to some users as content might not otherwise be accessible at all.

Who benefits:

1. Users with blindness, low vision, deafness, hard of hearing, and any user who requires the text source to understand the content.

Example techniques:

1. Make the text view useful. For instance, enable links (i.e., URIs), allowing searching and other navigation within the view.
2. A source view is an easily-implementable view that will help users inspect some types of content, such as style sheet fragments or scripts. This does not mean, however, that a source view of style sheets is the best user interface for reading or changing style sheets.

Doing more:

1. Provide a source view for any text format, not just implemented text formats.

Notes and rationale:

1. There may be more than one piece of conditional content associated with another piece of content (e.g., multiple captions tracks associated with the visual track of a presentation).
2. Please note that the alert requirement of this checkpoint is per-element. A single resource-level alert (e.g., "there is conditional content somewhere here") does not satisfy the checkpoint, but may be part of a solution for satisfying this checkpoint. For example, the user agent might indicate the presence of conditional content "somewhere" with menu in the toolbar. The menu items could provide both per-element alert and access to the content (e.g., by opening a viewport with the conditional content rendered).

Who benefits:

1. Any user for whom the author has provided conditional content for accessibility purposes. This includes: text equivalents for users with blindness or low vision, or users who are deaf-blind, and captions, for users who with deafness or who are hard of hearing.

Example techniques:

1. Allow users to choose more than one piece of conditional content at a given time. 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 synthesized speech.
2. In HTML 4 [HTML4], conditional content mechanisms include the following:
   • For the IMG element (section 13.2): the "alt" (section 13.8), "title" (section 7.4.3), and "longdesc" (section 13.2) attributes. See 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).
3. Allow the user to configure how the user agent renders a long description (e.g., "longdesc" in HTML 4 [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.
4. 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 conditional content should be rendered. For example, within the specified geometry, by ignoring the specified geometry altogether, etc.
5. 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 example, construct a list of all available tracks from short descriptions provided by the author (e.g., through the "title" attribute).
6. For multimedia presentations with several alternative tracks, allow users to choose 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).
7. 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. 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.
8. Make apparent through the user agent user interface which audio tracks are meant to be played separately.

Related techniques:

1. See the section on access to content.

Doing more:

1. Make information available with different levels of detail. For example, for a voice browser, offer two options for HTML IMG elements:
   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.
2. Allow the user to configure different natural language preferences for different types of conditional content (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 supplementary 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.

   

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

Notes and rationale:

1. The user agent could satisfy this checkpoint by allowing the user to step through an entire presentation manually (as one might advance frame by frame through a movie). However, this is likely to be tedious and lead to information loss, so the user agent should preserve as much of the flow and order of the original presentation as possible.
2. The requirement to pause at the end (rather than at the beginning) of a time-interval is to allow the user to review content that may change during the elapse of this time.
3. The configuration option is important because techniques used to satisfy this checkpoint may lead to information loss for some types of content (e.g., highly interactive real-time presentations).
4. When different streams of time-sensitive content are not synchronized (and rendered in the same or different viewports), the user agent is not required to pause the pieces all at once. The assumption is that both streams of content will be available at another time.

Who benefits:

1. Some users with a physical disability who may not have the time to interact with the content. Also, users who may be accessing the content serially (e.g,. users with blindness or some users with a physical disability) and require more time to reach the timed content

Example techniques:

1. Some HTML user agents recognize time intervals specified through the META element, although this usage is not defined in HTML 4 [HTML4].
2. 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.
3. For a presentation that is not "live", allow the user to choose from a menu of available time-sensitive links (essentially making them time-independent).

Doing more:

1. Provide a view where time intervals are lengthened, but not infinitely (e.g., allow the user to multiple time intervals by 3, 5, and 10). Or, allow the user to add extra time (e.g., 10 seconds) to each time interval.
2. Allow the user to view a list of all media elements or links of the presentations sorted by start or end time or alphabetically.
3. Alert the user whenever pausing the user agent may lead to packet loss.

References:

1. Refer to section 4.2.4 of SMIL 1.0 [SMIL] for information about the SMIL time model.

Notes and rationale:

1. Users may wish to a read transcript at the same time as a related visual or audio track and pause the visual or audio track while reading; see checkpoint 4.5.

Who benefits:

1. Users with blindness or low vision (auditory descriptions and text captions, etc.) and users with deafness or who are hard of hearing.

Example techniques:

1. Allow users to turn on and off auditory descriptions and captions.
2. For the purpose of applying this clause, SMIL 1.0 [SMIL] user agents should recognize as captions any media object whose reference from SMIL is guarded by the 'system-captions' test attribute.
3. 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 [SMIL] does not include a mechanism analogous to 'system-captions' for auditory descriptions, though [SMIL20] is expected to.
4. Another SMIL 1.0 test attribute, 'system-overdub-or-captions', allows users to choose between subtitles and overdubs in multilingual presentations. User agents should not interpret a value of 'caption' for this test attribute as meaning that the user prefers accessibility captions; that is the purpose of the 'system-captions' test attribute. When subtitles and accessibility captions are both available, users who are deaf may prefer to view captions, as they generally contain information not in subtitles: information on music, sound effects, who is speaking, etc.
5. User agents that play QuickTime movies should allow the user to turn on and off the different tracks embedded in the movie. Authors may use these alternative tracks to provide content for accessibility purposes. The Apple QuickTime player provides this feature through the menu item "Enable Tracks."
6. 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 that play Microsoft Windows Media Object presentations should allow users to turn on and off other conditional content, including auditory description and alternative visual tracks.

References:

1. User agents that implement SMIL 1.0 [SMIL] should implement the "Accessibility Features of SMIL" [SMIL-ACCESS].

Notes and rationale:

1. The term "synchronization cues" refers to pieces of information that may affect synchronization, such as the size and expected duration of tracks 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).
2. Captions and auditory descriptions may not make sense unless rendered synchronously with related video or audio content. For instance, if someone with a hearing disability is watching a video presentation and reading associated captions, the captions should be synchronized with the audio so that the individual can use any residual hearing. For auditory descriptions, it is crucial that an audio track and an auditory description track be synchronized to avoid having them both play at once, which would reduce the clarity of the presentation.

Who benefits:

1. Users with deafness or who are hard of hearing (e.g., for auditory descriptions and audio tracks), and some users with a cognitive disability.

Example techniques:

1. For synchronization in SMIL 2.0 [SMIL20], refer to section 10, the timing and synchronization module.
2. 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. Typically, a segment of the captions appears visually near the video for several seconds while the person reads the text. As the visual track continues, a new segment of the captions is presented. However, a problem arises if the captions are longer than can fit in the display space. This can be particularly difficult if due to a visual disability, the font size has been enlarged, thus reducing the amount of rendered caption text that can be presented. The user agent needs to 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.
3. Developers of user agents need to determine how they will handle other synchronization challenges, such as:
   1. Under what circumstances will the presentation automatically pause? Some circumstances where this might occur include:
      • the segment of rendered caption text is more than can fit on the visual display
      • the user wishes more time to read captions or the collated text transcript
      • the auditory description is of longer duration than the natural pause in the audio.
   2. Once the presentation has paused, then under what circumstances will it resume (e.g., only when the user signals it to resume, or based on a predefined pause length)?
   3. If the user agent allows the user to jump to a location in a presentation by activating a link, then how will related tracks behave? Will they jump as well? Will the user be able to return to a previous location or undo the action?

Notes and rationale:

1. Some examples of missing conditional content that is required by format specification:
   • in HTML 4 [HTML4], "alt" is required for the IMG and AREA elements (for validation). In SMIL 1.0 [SMIL], on the other hand, "alt" is not required on media objects.
   • whatever the format, text equivalents for non-text content are required by the Web Content Accessibility Guidelines 1.0 [WCAG10].
2. Conditional content may come from markup, inside images (e.g., refer to "Describing and retrieving photos using RDF and HTTP" [PHOTO-RDF]), etc.

Who benefits:

1. Users with blindness or low vision.

Example techniques:

1. When HTTP is used, HTTP headers provide information about the URI of the Web resource ("Content-Location") and its type ("Content-Type"). Refer to the HTTP/1.1 specification [RFC2616], sections 14.14 and 14.17, respectively. Refer to "Uniform Resource Identifiers (URI): Generic Syntax" ([RFC2396], section 4) for information about URI references, as well as the HTTP/1.1 specification [RFC2616], section 3.2.1.

Related techniques:

1. See content repair techniques, and cell header repair strategies.

Doing more:

1. When configured to generate text, also inform the user (e.g., in the generated text itself) that this content was not provided by the author as a text equivalent.

References:

1. The "Altifier Tool" [ALTIFIER] illustrates smart techniques for generating text equivalents (for images, etc.) when the author has not specified any.

Notes and rationale:

1. User agents should render nothing in this case because the author may specify an empty text equivalent for content that has no function in the page other than as decoration.

Who benefits:

1. Users with blindness or low vision.

Example techniques:

1. The user agent should not render generic labels such as "[INLINE]" or "[GRAPHIC]" in the face of empty conditional content (unless configured to do so).
2. If no captioning information is available and captioning is turned on, render "no captioning information available" in the captioning region of the viewport (unless configured not to generate repair content).

Doing more:

1. Labels (e.g., "[INLINE]" or "[GRAPHIC]") may be useful in some situations, so the user agent may allow configuration to render "No author text" (or similar) instead of empty conditional content.

Who benefits:

1. Any user who may have difficulties with navigation and manual access to content, including some users with a physical disability and users with blindness or low vision.

Example techniques:

1. Provide a "conditional content view", where all content that is not rendered by default is rendered in place of associated content. For example, Amaya [AMAYA] offers a "Show alternate" view that accomplishes this. Note, however, cases where an element has more than one piece of associated conditional content (e.g., render them all as a list, or as a list of links, etc.). For long conditional content, instead of rendering in place, link to the content.

Who benefits:

1. Some users with a cognitive disability may find it difficult to access content once too many images (for example) have been rendered one by one.

Example techniques:

1. Allow the user to designate a placeholder and request to view the associated content in a separate viewport (e.g., through the context menu), leaving the placeholder in context. Per checkpoint 5.3, users are able to close the new viewport.

Notes and rationale:

1. A script is a means of supporting the visual rendering of content in a particular natural language. So, for user agents that render content visually, a user agent might not recognize "the Cyrillic script", which would mean that it would not support the visual rendering of Russian, Ukrainian, and other languages that employ Cyrillic when written.
2. Rendering content in an unsupported language (e.g., as "garbage" characters) may confuse all users. However, this checkpoint is designed primarily to benefit users who access content serially as it allows them to skip portions of content that would be unusable as rendered.
3. There may be cases when a conforming user agent supports a natural language but a speech synthesizer does not, or vice versa.

Who benefits:

1. Users who access content serially, including users with blindness and some users with a physical disability.

Example techniques:

1. 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 "Unsupported language – unable to render" (e.g., when the language itself is not recognized) or "Korean not supported – unable to render" (e.g., when the language is recognized by the user agent doesn't have resources to render it). The user should also be able to choose no alert of language changes. Rendering could involve speaking in the designated natural language in the case of a voice browser or screen reader. If the natural language is not supported, the language change alert could be spoken in the default language by a screen reader or voice browser.
2. A user agent may not be able to render all characters in a document meaningfully, for instance, because the user agent lacks a suitable font, a character has a value that may not be expressed in the user agent's internal character encoding, etc. In this case, section 5.4 of HTML 4 [HTML4] recommends the following for undisplayable characters:
   1. Adopt a clearly visible (or audible), but unobtrusive mechanism to alert the user of missing resources.
   2. If missing characters are presented using their numeric representation, use the hexadecimal (not decimal) form since this is the form used in character set standards.
3. When HTTP is used, HTTP headers provide information about content encoding ("Content-Encoding") and content language ("Content-Language"). Refer to the HTTP/1.1 specification [RFC2616], sections 14.11 and 14.12, respectively.
4. CSS2's attribute selector may be used with the HTML "lang" or XML "xml:lang" attributes to control rendering based on recognized natural language information. Refer also to the ':lang' pseudo-class ([CSS2], section 5.11.4).

Related techniques:

1. See techniques for generated content, which may be used to insert text to indicate a language change.
2. See content repair techniques and accessibility and internationalization techniques.
3. See techniques for synthesized speech.

References:

1. For information on language codes, refer to "Codes for the representation of names of languages" [ISO639].
2. 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.

Notes and rationale:

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

Who benefits:

1. Some users with a cognitive disability or color deficiencies who may find it difficult or impossible to read superimposed text or understand other superimposed content.

Example techniques:

1. If background image are turned off, make available to the user associated conditional content.
2. In CSS, background images may be turned on/off with the 'background' and 'background-image' properties ([CSS2], section 14.2.1).

Doing more:

1. Allow control of image depth in multi-layer presentations.

Who benefits:

1. Some users with a cognitive disability, for whom an excess of visual information (and in particular animated information) might it impossible to understand parts of content. Also, audio rendered automatically on load may interfere with speech synthesizers.

Example techniques:

1. For user agents that hand off content to different rendering engines, the configuration should cause the content not to be handed off, and instead a placeholder rendered.
2. The "silent" or "invisible" solution for satisfying this checkpoint (e.g., by implementing the 'visibility' property defined in section 11.2 of CSS 2 [CSS2]). is not recommended. This solution means that the content is processed, though not rendered, and processing may cause undesirable side effects such as firing events. Or, processing may interfere with the processing of other content (e.g., silent audio may interfere with other sources of sound such as the output of a speech synthesizer). This technique should be deployed with caution.
3. As a placeholder for an animated image, render a motionless image built from the first frame of the animated image.

Notes and rationale:

1. The definition of blinking text is based on the CSS2 definition of the 'blink' value; refer to [CSS2], section 16.3.1.

Who benefits:

1. Flashing content may trigger seizures in people with photosensitive epilepsy, or may make a Web page too distracting to be usable by someone with a cognitive disability. Blinking text can affect screen reader users, since screen readers (in conjunction with speech synthesizers or braille displays) may re-render the text every time it blinks.
2. Configuration is preferred as some users may benefit from blinking effects (e.g., users who are deaf or hard of hearing). However, the priority of this checkpoint was assigned on the basis of requirements unrelated to this benefit.

Example techniques:

1. The user agent may render the motionless text in a number of ways. Inline is preferred, but for extremely long text, it may be better to render the text in another viewport, easily reachable from the user's browsing context.
2. 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).
3. Some sources of blinking and moving text are:
   • The BLINK element in HTML. Note: The BLINK element is not defined by a W3C specification.
   • The MARQUEE element in HTML. Note: The MARQUEE element is not defined by a W3C specification.
   • The 'blink' value of the 'text-decoration' property in CSS ([CSS2], section 16.3.1).
   • In JavaScript, to control the start and speed of scrolling for a MARQUEE element:
     • document.all.myBanner.start();
     • document.all.myBanner.scrollDelay = 100

Notes and rationale:

1. Executable content includes scripts, applets, ActiveX controls, etc. This checkpoint does not apply to plug-ins; they are not part of content.
2. Executable content includes those that run "on load" (e.g., when a document loads into a viewport) and when other events occur (e.g., user interface events).
3. The alert that scripts are available but not executed is important, for instance, for helping users understand why some poorly authored pages without script alternatives produce no content when scripts are turned off.
4. Where possible, authors should encode knowledge in declarative formats rather than in scripts. Knowledge and behaviors embedded in scripts is difficult to extract, which means that user agents are less likely to be able to offer control by the user over the script's effect.

Who benefits:

1. Control of executable content is particularly important as it can cause the screen to flicker, since people with photosensitive epilepsy can have seizures triggered by flickering or flashing, particularly in the 4 to 59 flashes per second (Hertz) range. Peak sensitivity to flickering or flashing occurs at 20 Hertz.

Example techniques:

1. Do not make available the switch to turn scripts off only in the "Security" part of the user interface as people may not think to look there. For instance, include a "Scripts" entry in the index that allows people to find the switch more easily.

Related techniques:

1. See the section on script techniques.

Doing more:

1. While this checkpoint only requires an on/off configuration switch, user agents should allow finer control over executable content. For instance, in addition to the switch, allow users to turn off just input device event handlers, or to turn on and off scripts in a given scripting language only.

Notes and rationale:

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

Who benefits:

1. Automatically changing content can disorient some users with a cognitive disability, users with blindness or low vision, and most users.

Example techniques:

1. Alert the user that suppressing refresh may lead to loss of information (i.e., packet loss).

Doing more:

1. Allow users to specify their own refresh rate.
2. Allow configuration for at least one very slow refresh rate (e.g., every 10 minutes).
3. Retrieve new content without displaying it automatically. Allow the user to view the differences (e.g., by highlighting or filtering) between the currently rendered content and the new content (including no differences).

Notes and rationale:

1. This checkpoint is a Priority 2 checkpoint in part because the author's redirect implies that users aren't expected to use the content prior to the redirect.

Who benefits:

1. Automatically changing content can disorient some users with a cognitive disability, users with blindness or low vision, and most users.

Example techniques:

1. Provide a configuration so that when the user navigates "back" through the user agent history to a page with a client-side redirect, the user agent does not re-execute the client-side redirect.

Doing more:

1. Allow configuration to allow access on demand to new content even when the client-side redirect has been specified by the author to be instantaneous.

References:

1. For Web content authors: refer to the HTTP/1.1 specification [RFC2616] for information about using server-side redirect mechanisms (instead of client-side redirects).

Notes and rationale:

1. This priority of checkpoint 3.2 is higher than the priority of this checkpoint because an excess of moving visual information is likely to be more distracting to some users than an excess of still visual information.

Who benefits:

1. Some users with a cognitive disability, for whom an excess of visual information might it difficult to understand parts of content.

Related techniques:

1. See techniques for checkpoint 3.1.

Notes and rationale:

1. For example, allow the user to configure the user agent to apply the same font family across Web resources, so that all text is displayed by default using that font family. Or, allow the user to control the text size dynamically for a given element, e.g., by navigating to the element and zooming in on it.
2. The choice of optimal techniques depends in part on which markup language is being used. For instance, HTML user agents may allow the user to change the font size of a particular piece of text (e.g., by using CSS user style sheets) independent of other content (e.g., images). Since the user agent can reflow the text after resizing the font, the rendered text will become more legible without, for example, distorting bitmap images. On the other hand, some languages, such as SVG, do not allow text reflow, which means that changes to font size may cause rendered text to overlap with other content, reducing accessibility. SVG is designed to scale, making a zoom functionality the more natural technique for SVG user agents satisfying this checkpoint.
3. The primary intention of this checkpoint is to allow users with low vision to increase the size of text. Full configurability includes the choice of (very) small text sizes that may be available, though this is not considered by the User Agent Accessibility Guidelines Working Group to be part of the priority 1 requirement. This checkpoint does not include a "lower bound" (above which text sizes would be required) because of how users' needs may vary across writing systems and hardware.

Who benefits:

1. Users with low vision benefit from the ability to increase the text size. Note that some users may also benefit from the ability to choose small font sizes (e.g., users of screen readers who wish to have more content per screen so they have to scroll less frequently).

Example techniques:

1. Inherit text size information from user preferences specified for the operating environment.
2. Use operating environment magnification features.
3. When scaling text, maintain size relationships among text of different sizes.
4. Implement the 'font-size' property in CSS ([CSS2], section 15.2.4).
5. For example, in Windows, the ChooseFont function in the Comdlg32 library will create the conventional utility of that operating system that allows users to choose text (font) size. The DrawText API is the lower-level API for drawing text.

Doing more:

1. Allow the user to configure the text size on an element level (i.e., more precisely than globally). User style sheets allow such detailed configurations.
2. Allow the user to configure the text size differently for different scripts (i.e., writing systems).

Who benefits:

1. Users with low vision or some users with a cognitive disability or reading disorder require the ability to change the font family of text in order to read it.

Example techniques:

1. Inherit font family information from user preferences specified for the operating environment.
2. Implement the 'font-family' property in CSS ([CSS2], section 15.2.2).
3. Allow the user to override author-specified font families with differing levels of detail. For instance, use font A in place of any sans-serif font and font B in place of any serif font.
4. For example, in Windows, the ChooseFont function in the Comdlg32 library will create the conventional utility of that operating system that allows users to choose font families. The DrawText API is the lower-level API for drawing text.

Doing more:

1. Allow the user to configure font families on an element level (i.e., more precisely than globally). User style sheets allow such detailed configurations.

Who benefits:

1. Users with color deficiencies and some users with a cognitive disability.

Example techniques:

1. Inherit foreground and background color information from user preferences specified for the operating environment.
2. Implement the 'color' and 'border-color' properties in CSS 2 ([CSS2], sections 14.1 and 8.5.2, respectively).
3. Implement the 'background-color' property (and other background properties) in CSS 2 ([CSS2], section 14.2.1).
4. SMIL does not have a global property for "background color", but allows specification of background color by region (refer, for example, to the definition of the 'background-color' attribute defined in section 3.3.1 of SMIL 1.0 [SMIL]). In the case of SMIL, the user agent would satisfy this checkpoint by applying the users preferred background color to all regions (and to all root-layout elements as well). SMIL 1.0 does not have a way to specify the foreground color of text, so that portion of the checkpoint would not apply.
5. In SVG 1.0 [SVG], the 'fill' and 'stroke' properties are used to paint foreground colors.
6. For example, in Windows, the ChooseColor function in the Comdlg32 library will create the conventional utility of that operating system that allows users to choose colors. The DrawText API is the lower-level API for drawing text.

Doing more:

1. Allow the user to specify minimal contrast between foreground and background colors, adjusting colors dynamically to meet those requirements.

Notes and rationale:

1. Slowing one track (e.g., video) may make it harder for a user to understand another synchronized track (e.g., audio), but if the user can understand content after two passes, this is better than not being able to understand it at all.
2. Some formats (e.g., streaming formats), might not enable the user agent to slow down playback and would thus be subject to applicability.

Who benefits:

1. Some users with a learning or cognitive disability, or some users with newly acquired sensory limitations (such as a person who is newly blind and learning to use a screen reader). Users who have beginning familiarity with a natural language may also benefit.

Example techniques:

1. When changing the rate of audio, avoid pitch distortion.
2. HTML 4 [HTML4], background animations may be specified with the deprecated background attribute.
3. The SMIL 2.0 Time Manipulations Module ([SMIL20], chapter 11) defines the speed attribute, which can be used to change the playback rate (as well as forward or reverse direction) of any animation.
4. Authors sometimes specify background sounds with the "bgsound" attribute. Note: This attribute is not part of HTML 4 [HTML4].

Doing more:

1. Allowing the user to speed up audio is also useful. For example, some users who access content serially benefit from the ability to speed up audio.

References:

1. Refer to variable playback speed techniques used for Digital Talking Books [TALKINGBOOKS].

Notes and rationale:

1. Some formats (e.g., streaming formats), might not enable the user agent to fast forward or rewind content and would thus be subject to applicability.
2. For some streaming media formats, the user agent might not be able to offer some functionalities (e.g,. fast forward) when the content is being delivered over th