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 access, sequential access, and access through two-dimensional visual space. 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 two-dimensional visual 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), and drag-and-drop (allow the user to designate start and end points and then say "go").
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 use 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 such as a Web browser does not allow complete operation through the keyboard alone. It is still possible to claim conformance for the combination of the user agent and a software component that performs the necessary functions.

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 navigation in two-dimensional visual space.
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 using 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, for example, keyboard-operable cascading menus, context-sensitive help, and keyboard operable configuration tabs) 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. When using the "Document Object Model (DOM) Level 2 Events Specification" [DOM2EVENTS], activate an event handler as described in section 1.5:
   1. Create an event of the given type by calling DocumentEvent.createEvent, which takes an event type as parameter, then
   2. Dispatch this event using EventTarget.dispatchEvent.
2. 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 an onmousedown event. Once triggered, the menu would not allow onmousedown but would allow onmouseup and onmouseover.
3. In some markup languages, it is possible (though somewhat nonsensical) for two actions to be assigned to the same input event type for a given element (e.g., one through an explicit event handler and one "intrinsic" to the element). In this case, offer the user a choice of which action to take.
4. 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.
5. 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.
6. 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.
7. The DOM Level 2 Events specification does not provide a key event module.
8. Sequential navigation technique: Add each input device event handler to the 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 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.
9. Query technique: Allow the user to query the element with content focus for a menu of input device event handlers.
10. 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 AccessibleAction Java interface. This interface provides a list of actions and descriptions that enable selective activation. See also checkpoint 6.3.
11. 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 information on how to register event handlers through the DOM, and dispatch events properly, refer to Section 1.3 Event listener registration in "Document Object Model (DOM) Level 2 Events Specification" [DOM2EVENTS].
2. 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 proportional scroll bars are used in the graphical interface 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. Provision two of the checkpoint 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 automatic content retrieval), 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. In the absence of authoritative Internet media type information to the contrary, provide a text view of any media object identified as XML or SGML by a DOCTYPE indication conforming to the rules of those formats. User agents receive media objects in many ways. The HTTP protocol is somewhat reliable as regards providing Internet media type information for the data so delivered. The file: and ftp: URI schemes, on the other hand, do not provide this metadata. In cases like these, using the built-in markings of XML and SGML objects is appropriate and should be expected.

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. 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, or by ignoring the specified geometry altogether.
5. For multimedia presentations with several alternative tracks, ensure access to all tracks and allow the user to select individual tracks. (As an example, 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, for example, in level of detail, reading level or natural language. 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 audio descriptions concurrently as well.
8. Make apparent through the user agent user interface which audio tracks are meant to be played separately (e.g., by allowing the user to select each one independently from a menu).
9. Section 7.8.1 of SMIL 2.0 [SMIL20] defines the readIndex attribute, which specifies the position of the current element in the order in which values of the longdesc, title, and alt attributes are to be read aloud.

Related techniques

1. See the section on access to content.

Doing more

1. If the user agent satisfies the checkpoint by implementing 1b (placeholders), allow the user to toggle back and forth between a placeholder and the original author-supplied content. Some users with a cognitive disability may find it difficult to access content after turning on rendering of too many images (even when those images were turned on one by one). A sample technique is to allow the user to designate a placeholder and request to view the associated content in a separate viewport (e.g., through a context menu), leaving the placeholder in context. Allow the user to close the new viewport manually.
2. 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.
3. Allow the user to configure different natural language preferences for different types of conditional content (e.g., captions and audio 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.

   D

   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, and users with serial access to content or who navigate sequentially.

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 a 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 (audio descriptions and text captions) and users with deafness or who are hard of hearing.

Example techniques

1. Allow users to turn on and off audio 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 audio descriptions. Note: SMIL 1.0 [SMIL] does not include a mechanism analogous to system-captions for audio descriptions, though [SMIL20] does, called systemAudioDesc.
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, including information on music, sound effects, and who is speaking.
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 audio description and alternative visual tracks.

References

1. Developers implementing SMIL 1.0 [SMIL] should consult "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 audio 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 audio descriptions, it is crucial that an audio track and an audio 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 audio 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 next segment of the visual track.
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 audio 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. Following are some examples of conditional content that is required by format specification:
   • In HTML 4 [HTML4], the alt attribute 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, or even inside images (e.g., refer to "Describing and retrieving photos using RDF and HTTP" [PHOTO-RDF]).

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.
2. An image or another piece of content may appear several times in content. If one instance has associated conditional content but others do not, reuse what the author did provide.
3. Repair content may be part of another piece of content. For instance, some image formats allow authors to store metadata there; refer to "Describing and retrieving photos using RDF and HTTP" [PHOTO-RDF].

Related techniques

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

Doing more

1. When configured per provision one of this checkpoint, inform the user (e.g., in the generated text itself) that this content was not provided by the author.
2. Use heuristics based on the specification format. For instance, if the alt attribute is missing on the IMG element in HTML, but the title attribute is present, base the repair content on the title.

References

1. The "Altifier Tool" [ALTIFIER] illustrates smart techniques for generating text equivalents (e.g., for images) when the author has not specified any.
2. Additional repair techniques may be available from W3C's Evaluation and Repair Tools Working Group.

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]" for 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. Users who 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. For long conditional content, instead of rendering in place, link to the content.

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. 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 with serial access to content or who navigate sequentially.

Example techniques

1. Use a text substitute or accessible graphical icon to indicate that content in a particular language has not been rendered. For instance, a user agent that does not support Korean (e.g., does not 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 does not 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. For instance, 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 language ("Content-Language"). Refer to the HTTP/1.1 specification [RFC2616], section 14.12.
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.

Doing more

1. The UAWG recognizes that the intent of this checkpoint -- to reduce confusion and save time for the user -- applies to text rendered as speech or braille as well, but those requirements are not part of UAAG 1.0, in part due to lack of implementation experience.

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 images 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 make 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. Users with photosensitive epilepsy (for whom flashing content may trigger seizures) and users with some cognitive disorders (for whom the distraction may make the content unusable). Blinking text can also 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. The BLINK element is not defined by a W3C specification.
   • The MARQUEE element in HTML. 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, and ActiveX controls. 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. Where possible, authors should encode knowledge in a declarative manner (i.e., through static definitions and expressions) rather than in scripts. Knowledge and behaviors embedded in scripts can be difficult or impossible to extract, which means that user agents are less likely to be able to offer control by the user over the script's effect. For instance, with SVG animation (see chapter 19 of SVG 1.0 [SVG]), one can create animation effects in a declarative manner, using recognizable elements and attributes.

Who benefits

1. Some users with photosensitive epilepsy; flickering or flashing, particularly in the 4 to 59 flashes per second (hertz) range, may trigger seizures. Peak sensitivity to flickering or flashing occurs at 20 hertz. Some executable content can cause the screen to flicker.

Example techniques