Copyright © 1999 W3C®
(MIT, INRIA, Keio), All Rights Reserved. W3C liability,
trademark,
document
use and software
licensing rules apply.
This document summarizes the accessibility features of the Synchronized Multimedia Language (SMIL), version 1.0 Recommendation ([SMIL10]). This document has been written so that other documents may refer in a consistent manner to the accessibility features of SMIL.
This document is a draft W3C Note made available by the W3C and the W3C Web Accessibility Initiative. This NOTE has not yet been jointly approved by the WAI Education and Outreach Working Group (EOWG), the WAI Protocols and Formats Working Group (PFWG), and the Synchronized Multimedia (SYMM) Working Group.
Publication of a W3C Note does not imply endorsement by the W3C Membership. A list of current W3C technical reports and publications, including working drafts and notes, can be found at http://www.w3.org/TR.
Multimedia presentations rich in text, audio, video, and graphics are becoming more and more common on the Web. They include newscasts, educational material, entertainment, etc. Formats such as SMIL 1.0 can be used to create dynamic multimedia presentations by synchronizing the various media elements in time and space.
Authors can make SMIL 1.0 presentations accessible to users with disabilities by observing the principles discussed in the "Web Content Accessibility Guidelines 1.0" [WAI-WEBCONTENT]. The Guidelines explain how to create documents that account for the diverse abilities, tools, and software of all Web users, including people with combinations of visual, auditory, physical, cognitive, and learning disabilities. This does not mean creating a great number of separate presentations but rather one integrated and accessible presentation. The purpose of this Note is to explain which SMIL 1.0 features will help you create accessible presentations.
Dynamic multimedia presents a number of challenges to people with disabilities and to authors of accessible content:
Part of the responsibility for making SMIL 1.0 presentations accessible lies with the author and part with the user's software, the SMIL player. Authors must include equivalent alternatives for images, video, audio, and other inaccessible media. Authors must synchronize media objects correctly, describe relationships among objects, and design documents that will work well with user accessibility preferences in SMIL players (e.g., support for captions). Authors should design documents that transform gracefully for players that do not support a particular feature (e.g., style sheets). And, authors should design documents so that players can support user control (e.g., authors must not misuse markup such as test attributes to force or prevent rendering of content).
In turn, SMIL players must allow users to control document presentation to ensure its accessibility. The "User Agent Accessibility Guidelines" [WAI-USERAGENT] explain principles for creating accessible user agents. User control of presentation and configurability are central to these guidelines.
For instance, users with low vision must be able to enlarge a presentation, whatever the author's original design. Users with color deficiencies must be able to specify suitable color contrasts, even if that means overriding the author's preferences.
Players must provide users access to author-supplied media objects, their accessible alternatives, or both. Users must also be able to turn on and off alternatives and control their size, position, and volume. For instance, users with both low vision and hearing loss must be able to enlarge text captions. Users might also want to specify how to render synchronized audio tracks, for instance, by changing the volume or other available attributes of an auditory description to distinguish it from the audio track.
Since users with some cognitive disabilities or people using combinations of assistive technologies such as refreshable Braille and speech synthesis may require additional time to view a presentation or its captions, players must allow them to start, stop, and pause a presentation (as one can do with most home video players). Where possible, users should be able to control the global presentation rate. Some users may require that time-sensitive information be rendered in a time-independent form altogether. For example, SMIL 1.0 allows authors to designate graphical regions that are linked to different resources at different times. Some users may not have enough time to select a link with a limited lifespan, or even to notice it. Therefore, players should provide access to them in a time-independent manner. Multimedia players may also offer an index to time-dependent information in a time-independent form.
This Note describes the accessibility features of [SMIL10] and explains how authors and SMIL players should make use of them. Note. Recommendations for authors and SMIL players are made in accordance with the recommendations made in [WAI-WEBCONTENT] and [WAI-USERAGENT].
Specifying synchronization in SMIL offers some advantages over relying on time codes in external resources. One advantage is that authors may use relative timing with par, seq, begin, end, and dur elements instead of absolute time codes alone. This may promote accessibility since timing relationships described relatively may be more easily controlled and changed according to user needs. Therefore they may be adapted to a variety of output devices and scenarios (just as relative layouts may be scaled graphically).
In most of the examples in this document, the only synchronization among media objects specified in SMIL is done by using the par element to synchronize beginnings. We assume that other necessary synchronization (e.g., between video and audio) has been specified in the formats that encode the media objects.
Note. In the examples below, "rt" suggests a "real text" media object file, "rm" a real audio file, and "mpeg" an MPEG file.
Multimedia presentations may include two main types of equivalent alternatives: discrete and continuous. Discrete equivalents do not contain any time references or have intrinsic duration. In SMIL, discrete text equivalents are generally specified by attributes such as the alt attribute of the img element.
Continuous equivalents, such as text captions or auditory descriptions, have intrinsic duration and may contain references to time. For instance, a continuous text equivalent consists of pieces of text associated with a time code. Continuous equivalents may be constructed out of discrete equivalents, for instance by using the SMIL elements par (parallel) or seq (sequential) and the timing attributes begin, end and dur.Text equivalents are fundamental to accessibility since they may be rendered graphically, as speech, or by a braille device. In multimedia presentations, continuous text equivalents must be synchronized with other time-dependent media.
The Web Content Accessibility Guidelines also require that, until user agents can automatically read aloud the text equivalent of a video track, authors provide an auditory description of the important information of the video track of a multimedia presentation. This benefits users who may not be able to read text or may not have access to software or hardware for speech synthesis or braille. Note that if you have a caption and text-to-speech software, you can generate an auditory description. However, you must still ensure the proper synchronization of the generated speech track with the video track.
Other forms of continuous equivalents also promote accessibility but are not discussed in this document. Representations of sign language (for example, a video in which a person translates an audio track into sign language) benefit people with auditory limitations. Simplified sound tracks benefit people with cognitive difficulties or concentration-limiting disabilities.
The following sections describe in more detail the SMIL features for specifying discrete and continuous equivalents for video, audio, text, and other SMIL elements.
Discrete text equivalents, when rendered by players or assistive technologies to the screen, as speech, or on a dynamic braille display, allow users to make use of the presentation, even if they cannot make use of all of its content. For instance, providing a text equivalent of an image that is part of a link will enable someone with blindness to decide whether to follow the link. Authors specify discrete text equivalents for SMIL elements through the following attributes:
Other SMIL attributes including author and abstract specify text metadata about document elements. Metadata generally promotes accessibility by providing more context and orientation. Text metadata may be rendered to the screen, as speech, or on a refreshable braille display. Authors are encouraged to enrich their presentations with metadata.
The following example includes a video element that presents a dynamic graph to illustrate trends in Web commerce and privacy. The alt, title, and abstract attributes specify discrete text equivalents that provide information with different granularity. The longdesc attribute designates a more complete text equivalent of the video presentation, with details about what information is being displayed in the graph, the units of the graph, etc. The long description itself might also include links back to anchors associated with key points of the presentation (not shown here) so that users can navigate back and forth.
<video src="http://foo.com/graph.mpeg"
title="Web Trends: Graph 1"
alt="The number of online stores
and consumers is increasing, but privacy
is decreasing."
abstract="The number of Web users, online stores, and
the influence of Web communities are
all steadily increasing while privacy for
Web users is slowly diminishing. This graph
explains the trends and Web technologies
that will most impact the future of
Web commerce."
longdesc="http://foo.com/graph-description.htm"/>Note. The above example shows one usage of the alt and title attributes together. The SMIL 1.0 specification does clearly explain the relationship between the two attributes. We recommend that authors use title when alt is not available (e.g., to describe synchronization elements, link destinations, layout, etc.) The relationship between the attributes should be clarified by W3C Working Groups in an future version of SMIL.
Two continuous equivalents that promote accessibility are captions and auditory descriptions. A caption is a text transcript of spoken words and non-spoken sound effects that provides the same information as a presentation's audio stream and is synchronized with the video track of the presentation. Captions benefit people with deafness or who are hard of hearing. They also benefit anyone in a setting where audio tracks would cause disturbance, where ambient noise in the audio track or listening environment prevents them from hearing the audio track, or when they have difficulties understanding spoken language.
An auditory description is a recorded or synthesized voice that describes key visual elements of the presentation including information about actions, body language, graphics, and scene changes. Like captions, auditory descriptions must be synchronized with the video stream they describe. Additionally, they must be synchronized with other audio streams. Auditory descriptions are generally timed to play during natural pauses in dialog. However, there may be cases where these natural pauses are not long enough to accommodate a sufficient auditory description. In such cases, it will be necessary to pause the video in order to provide enough time for an extended auditory description. At the end of the description, the video should resume play automatically. Auditory descriptions benefit people with blindness or low vision. They also benefit anyone in an eyes-busy setting or whose devices cannot show the original video or graphical media object.
Below we discuss in more detail how to associate captions and auditory descriptions with multimedia presentations in SMIL 1.0 in a manner that allows users to control the presentation of the alternative stream. We also examine how SMIL 1.0 supports multilingual presentations and how this affects continuous equivalents for accessibility. For more information about synchronizing media objects, please consult the SMIL 1.0 specification ([SMIL10]).
In SMIL 1.0, captions may be included in a presentation with the textstream element. The following example plays an audio track, a video track, and a caption (via the textstream element) in parallel.
<par>
<audio alt="Interview with Harvey, English audio"
src="audio.rm"/>
<video alt="Interview with Harvey" src="video.rm"/>
<textstream alt="English captions for interview with Harvey"
src="closed-caps.rt">
</par>
The limitation of the previous example is that the user cannot easily turn on or off the caption.
Since user control of presentation is vital to accessibility, SMIL 1.0 allows authors to create presentations whose behavior varies depending on current player settings. When a SMIL element such as textstream has the system-captions test attribute with value "on" and the user has turned on captioning, the element will be rendered.
The following example is a movie that consists of four media object elements: a video track, an audio soundtrack, and text streams of captions and stock values (for the avid stock market tracker!). All the elements are to be played in parallel due to the par element. The caption will only be rendered if the user has turned on captioning.
<par>
<audio alt="My Favorite Movie, English audio" src="audio.rm"/>
<video alt="My Favorite Movie" src="video.rm"/>
<textstream alt="Stock ticker" src="stockticker.rt"/>
<textstream alt="English captions for My Favorite Movie"
system-captions="on"
src="closed-caps.rt">
</par>The system-captions attribute can also be used with elements other than textstream. Like the other SMIL test attributes (refer to [SMIL], section 4.4), system-captions acts like a boolean flag that returns "true" or "false" according to player settings. Section 3.1 illustrates how system-captions can be used to specify different presentation layouts according to whether the user has captioning turned on.
Note. Authors should only use system-captions="on" with elements that specify captions and system-captions="off" for caption-related effects such as layout changes. This allows players to distinguish accessibility captions from other types of content (which may allow them to avoid overlapping captions and other content automatically, for example).
In SMIL 1.0, auditory descriptions may be included in a presentation with the audio element. However, SMIL 1.0 does not provide a mechanism that allows users to turn on or off player support for auditory descriptions.
SMIL 1.0 allows authors to create multilingual presentations by using subtitles (which are text streams) and overdubs (which are audio streams) in another language. Multilingual presentations themselves do not pose accessibility problems. Indeed, providing additional tracks (even in a different language) will help many users.
However, since subtitles and overdubs may co-exist with text and audio streams provided for accessibility, authors of accessible multilingual presentations should be aware of how they interact. For instance, authors should lay out presentations so that captions and subtitles do not overlap on the screen. Audio tracks should not overlap unless carefully synchronized.
In SMIL 1.0, the system-overdub-or-caption test attribute allows users to select (through the player's user interface) whether they would rather have the player render overdubs or subtitles. Note. The term "caption" in "system-overdub-or-caption" does not refer to accessibility captions. Authors must not use this attribute to create accessibility captions; use system-captions instead.
The following example offers a movie in both Spanish and English. If the player is set for preferences of Spanish and overdubs, the Spanish audio track will be rendered. Otherwise the second audio track of the first switch element (the English audio track) will be rendered. Note that since there is only one set of captions (in English), they will be rendered when the player is set for captioning.
<par>
<switch> <!-- audio -->
<audio alt="My Favorite Movie, Spanish audio"
src="audio-es.rm"
system-overdub-or-caption="overdub"
system-language="es"/>
<audio alt="My Favorite Movie, English audio"
src="audio.rm"/>
</switch>
<video alt="My Favorite Movie" src="video.rm"/>
<textstream alt="Stock ticker" src="stockticker.rt"/<
<textstream alt="English captions for My Favorite Movie"
src="closed-caps.rt"
system-captions="on"/>
</par>To add Spanish subtitles to the example, the author would specify a second textstream element. The first textstream will be rendered if the player is set for captioning. If not, the second textstream element will be rendered if the user has set the player to prefer subtitles and Spanish.
<par>
<switch> <!-- audio -->
<audio alt="My Favorite Movie, Spanish audio"
src="audio-es.rm"
system-overdub-or-caption="overdub"
system-language="es"/>
<audio alt="My Favorite Movie, English audio"
src="audio.rm"/>
</switch>
<video alt="My Favorite Movie" src="video.rm"/>
<textstream alt="Stock ticker" src="stockticker.rt"/>
<switch> <!-- captions or subtitles -->
<textstream alt="English captions for My Favorite Movie"
src="closed-caps.rt"
system-captions="on"/>
<textstream alt="Spanish subtitles for My Favorite Movie"
src="subtitles-es.rt"
system-overdub-or-caption="caption"
system-language="es"/>
</switch>
</par>While subtitles only capture dialog in text, captions include dialog as well as text descriptions of off-screen information (e.g., sounds). Consequently, authors may reuse captions as subtitles but should not use subtitles alone as captions.
In the switch element, the three textstream elements are rendered in order of preference for Spanish captions, Spanish subtitles, or English captions. This design allows authors to reuse the captions as subtitles and to ensure that the textstream is not rendered twice when the player is set to support both.
<par>
<switch> <!-- audio -->
<audio alt="My Favorite Movie, Spanish audio"
src="audio-es.rm"
system-overdub-or-caption="overdub"
system-language="es"/>
<audio alt="My Favorite Movie, English audio"
src="audio.rm"/>
</switch>
<video alt="My Favorite Movie" src="video.rm"/>
<textstream alt="Stock ticker" src="stockticker.rt"/>
<switch> <!-- captions or subtitles -->
<textstream alt="Spanish captions for My Favorite Movie"
src="closed-caps-es.rt"
system-captions="on"
system-language="es"/>
<textstream alt="Spanish subtitles for My Favorite Movie"
src="closed-caps-es.rt"
system-overdub-or-caption="caption"
system-language="es"/>
<textstream alt="English Captions for My Favorite Movie"
src="closed-caps.rt"
system-captions="on"/>
</switch>
</par>Note. In SMIL 1.0, values for system-overdub-or-caption only refer to user preferences for either subtitles or overdubs; there are no values for the test attribute that refer to user preferences for neither or both.
While it is important for players to respect author-specified layout and style for a presentation, the author's design may not take into consideration variations in a user's abilities, hardware, software, or viewing environment. Players must allow users to control styles and layout, otherwise users with some disabilities may not be able to make use of a presentation at all. For instance, players may allow users to override author-specified layout, to control colors, text size, etc.
Authors may specify the graphical layout of SMIL 1.0 media objects through SMIL's basic layout language or with a style sheet language such as CSS [CSS1, CSS2]. Please note, however, that SMIL 1.0 does not specify how style sheets in a SMIL presentation apply inside referenced media objects.
Note. While SMIL 1.0 includes support for style sheets, SMIL 1.0 players as of the publication of this document do not support CSS. Refer to [SMIL-CSS-LAYOUT] for information about rendering SMIL basic layout with a CSS2 engine. The Web Content Accessibility Guidelines recommend that authors specify style through style sheets when supported by user agents (including SMIL players). One reason the guidelines recommend style sheets (refer to [CSS-ACCESS]) is that in the CSS2 cascade, user-specified style sheets can override author-specified style sheets (refer to the "!important" mechanism described in section 6.4.2 of [CSS2]).
Authors specify the graphical layout of a SMIL 1.0 presentation inside the layout element, using either the SMIL basic layout language or style sheets. SMIL's layout facilities allow authors to arrange rectangular regions graphically (via the region element), much like positioning in CSS2.
The following example illustrates how to regain space when captions are turned off or not supported. In this example, the same layout is specified with both the SMIL basic layout language and CSS2 style sheets. Due to their order in the switch element, the SMIL player will use the CSS style sheet if supported, otherwise it will use the SMIL layout. Note that the type attribute of the layout element specifies the MIME type of the style sheet language, here "text/css".
The example specifies two layouts. When the user has chosen to view captions, they appear in a region (the "captext" region) that takes up 20% of available vertical space below a region for the video presentation (the "capvideo" region), which takes up the other 80%. When the user does not wish to view captions, the video region takes up all available vertical space (the "video" region). The choice of which layout to use depends on the value of the system-captions test attribute.
<smil>
<head>
<switch>
<layout type="text/css">
{ top: 20px; left: 20px }
[region="video"] {top: 0px; height: 100%}
[region="capvideo"] {top: 0px; height: 80%}
[region="captext"] {top: 80%; height: 20%; overflow: scroll}
</layout>
<layout>
<region id="video" title="Full-size video pane"
top="0" height="100%" fit="meet"/>
<region id="capvideo"
title="Video pane for use with caption window"
top="0" height="80%" fit="meet"/>
<region id="captext" title="Caption pane"
top="80%" height="20%" fit="scroll"/>
</layout>
</switch>
</head>
<body>
<switch> <!-- if captions off use first region, else second -->
<par system-captions="on">
<video region="capvideo" src="movie-vid.rm"
alt="Video presentation of soccer match"
title="Finals of Women"s World Cup 1999"/>
<textstream region="captext" src="closed-caps.rt"
alt="English caption of soccer match"/>
</par>
<video region="video" src="movie-vid.rm"
alt="Video presentation of soccer match"
title="Finals of Women"s World Cup 1999"
system-captions="off"/>
</switch>
</body>
</smil>In the SMIL 1.0 basic layout language, the only style-related attribute that can be specified is background-color. Authors must ensure sufficient contrast between foreground and background colors of content, otherwise users with color deficiencies will not be able to perceive them. If background-color is set and media objects (e.g., video, text, etc.) have transparent backgrounds, authors must ensure that the colors exhibit sufficient contrast. Players must allow users to control background colors to ensure accessibility.
The show attribute on the "a" and anchor elements controls the behavior of the source document containing the link when the link is followed. The default value of the attribute is "replace", which means that the destination presentation replaces the current presentation (in the same window, in audio, etc.).
Two other values for the attribute, "new" and "pause", cause the destination presentation to appear in a new context (e.g., window). Opening new windows without warning may disorient some users with blindness or cognitive impairments and may simply bother others. SMIL players must help orient users when windows open or focus changes (e.g., by using audio cues, by providing a history mechanism so users can return to a familiar state, etc.). Until players do so, authors should provide clues in content (e.g., via the title attribute) whenever they intend to open a new window.
SMIL 1.0 includes a number of interesting linking features, including HTML-like hyperlinks and image maps (as well as video maps). SMIL 1.0 also allows authors to create time-dependent links that are only active during certain intervals of a presentation (as defined by the author). To make these hyperlinks accessible, authors must provide text information and SMIL players should allow users to control the link rendering.
To create an accessible image or video map, authors must describe the nature of each link in the map for users who cannot see or use the visual information. Authors provide the description via the title attribute on the "a" and anchor elements. This text description may be rendered by SMIL players on the screen or by assistive technologies as speech or dynamic braille.
Here is an example of a video clip with an associated map. Each link describes an active rectangular region of the video via the coords attribute.
<video src="http://www.w3.org/CoolStuff.rm">
<anchor href="http://www.w3.org/AudioVideo"
coords="0%,0%,50%,50%"
title="W3C Multimedia Activity"/>
<anchor href="http://www.w3.org/Style"
coords="50%,50%,100%,100%"
title="W3C Style Sheet Activity"/>
</video>With the anchor element, authors may associate a link source with spatial and temporal subparts of a media object. With the "a" element, authors may only associate a link source with a complete media object.
SMIL players should provide an equivalent text link for each graphical link (for example, using link text derived from the title attribute of the linking element or the alt attribute of an active media object inside the link). Text links are important to users with blindness or low vision who often navigate documents by jumping from link to link and having the link text rendered by a speech synthesizer or refreshable braille display. Until SMIL players provide alternative text links, authors should provide text links in addition to non-text links.
Authors may "hide" supplementary text links by causing them to be rendered underneath other content. This may be done by specifying a negative value for the z-index attribute. If the user turns off video or images, the links will appear. In the following example, the text links are rendered underneath the video content.
<smil>
<head>
<layout>
<region id="above"/>
<region id="below" z-index="-1"/>
</layout>
</head>
<body>
<par>
<video region="above"
title="Introduction to W3C Activities"
alt="W3C Activities"
longdesc="http://www.w3.org/Activity/Summary"
src="http://www.w3.org/CoolStuff.rm">
<anchor href="http://www.w3.org/AudioVideo"
coords="0%,0%,50%,50%"
title="W3C Multimedia Activity"/>
<anchor href="http://www.w3.org/Style"
coords="50%,50%,100%,100%"
title="W3C Style Sheet Activity"/>
</video>
<par region="below">
<a href="http://www.w3.org/AudioVideo">
<text title="W3C Multimedia Activity"
src="AV.txt"/></a>
<a href="http://www.w3.org/Style">
<text title="W3C Style Sheet Activity"
src="SS.txt"/></a>
</par>
</par>The time-dependent linking mechanisms offered by SMIL 1.0 pose an accessibility challenge to both authors and players. The following example from the SMIL 1.0 specification illustrates time-dependent linking. In the example, the duration of a video clip is split into two time intervals: from 0 to 5 seconds and from 5 to 10 seconds. A different link is associated with each of these intervals.
<video title="Introduction to W3C Activities"
alt="W3C Activities"
longdesc="http://www.w3.org/Activity/Summary"
src="http://www.w3.org/CoolStuff.rm">
<anchor href="http://www.w3.org/AudioVideo"
title="W3C Multimedia Activity"
begin="0s" end="5s"/>
<anchor href="http://www.w3.org/Style"
title="W3C Style Sheet Activity"
begin="5s" end="10s"/>
</video>Some users require more time than anticipated by the author to interact with the presentation. Therefore, SMIL players should either allow users to control the overall timing of the presentation or to access all links in a time-independent manner. Until SMIL players enable this, authors should make all time-dependent links available in a static form. This may be done in a variety of ways. For instance, authors might list all time-dependent links in a separate document (and link to it from the presentation). The static list of links should include information about when the links are active during the presentation. This type of catalog will help all users, and allow people to find information about all links associated with a particular media object or that are active at a particular moment of the presentation.
Navigation mechanisms help all users but are particularly important for users with blindness or cognitive impairments who may not be able to grasp the structure of a presentation through visual clues. In addition to HTML-like linking mechanisms that may be used to create site maps and navigation bars, SMIL allows authors to create "temporal navigation bars" that allow users to navigate directly to important points in time of a presentation.
As an example, we first identify key points in a presentation that includes three interviews conducted sequentially (Joe, Tim, then Judy). Each segment is marked by an anchor (identified by the "id" attribute).
<smil>
<head>
<layout>
<region id="video" top="0" height="100%" fit="meet"/>
</layout>
</head>
<body>
<video src="http://www.w3.org/BBC.rm"
region="video"
title="Future of the Web"
alt="Interview with Joe, Tim, and Judy for BBC"
abstract="The BBC interviews Joe, Tim, and Judy about
the Future of the Web. Joe and Tim talk about
social and technological impact. Judy
addresses the benefits to accessibility of
good design.">
<anchor id="joe" begin="0s" end="5s"
title="Joe interview on Web trends"/>
<anchor id="tim" begin="5s" end="10s"
title="Tim interview on Web trends"/>
<anchor id="judy" begin="10s" end="60s"
title="Judy interview on Web accessibility"/>
</video>Authors might add a temporal navigation bar in parallel with the presentation. The navigation bar takes up the lower 10% of the presentation, and consists of a photo of each of the interviewees that links to their interview. Selecting a link causes player to play that part of the video. Refer to the section on opening new windows for information about where the interview will be played.
<smil>
<head>
<layout>
<region id="video" top="0" height="90%" fit="meet"/>
<region id="joe" top="90%" height="10%" fit="meet"/>
<region id="tim" top="90%" height="10%"
left="35%" fit="meet"/>
<region id="judy" top="90%" height="10%" fit="meet"
left="70%" fit="meet"/>
</layout>
</head>
<body>
<par>
<video <-- Video presentation information here -->
</video>
<a href="#joe" title="Joe interview on Web trends>
<img alt="Joe" title="Photo of Joe" src="joe-photo.png"/>
</a>
<a href="#tim" title="Tim interview on Web trends>
<img alt="Tim" title="Photo of Tim" src="tim-photo.png"/>
</a>
<a href="#judy" title="Judy interview on Web accessibility>
<img alt="Judy" title="Photo of Judy" src="judy-photo.png"/>
</a>
</par>As mentioned earlier, the authors of SMIL 1.0 presentations can define alternative designs based on some user or system settings. The author can test these settings through test attributes set on various elements.
Test attributes for captions, overdubs, and language are described in Section 2.2. SMIL 1.0 also includes attributes to test the speed of connection and some characteristics of the player. For example, if a connection is slow, the author can suggest that players not download images. However, users may still want to download important images despite a slow connection. Authors should therefore use these attributes conservatively and players must allow users to override values for these attributes.
These are the SMIL 1.0 test attributes that may be used with synchronization elements:
The following example delivers different qualities of video based on available bandwidth. The player evaluates each of the choices in the switch element in order and chooses the first one whose system-bitrate value is equal to or greater to the speed of the connection between the media player and media server. No video will be played for connection speeds less than 10,000.
<switch> <!-- video -->
<video src="high-quality-movie.rm" system-bitrate="40000">
<video src="medium-quality-movie.rm" system-bitrate="24000">
<video src="low-quality-movie.rm" system-bitrate="10000">
</switch>Presentations that are specified in relative rather than absolute terms may be more easily adapted to a variety of output devices and viewing contexts. For example, specifying layout in terms of percentages means that layout may be scaled while preserving relationships among graphical regions. This promotes consistency of author-specified layout and user control of the final view.
In SMIL 1.0, relative values are:
Players may offer other scaling strategies such as graphical zoom.
The first place to learn more about SMIL is the Recommendation itself [SMIL10]. The Synchronized Multimedia home page at the W3C Web site also includes information about SMIL tutorials, SMIL authoring tricks, examples of interesting presentations, player support for SMIL, and links to other sources of information about SMIL.
For more information about making SMIL presentations accessible, authors should consult the Web Content Accessibility Guidelines ([WAI-WEBCONTENT]) and accompanying techniques document ([WAI-WEBCONTENT-TECHS]), which explains the guidelines in detail and with many examples. Although the techniques document emphasizes HTML and CSS, many of the principles and examples apply to SMIL as well. Please note that these Guidelines assign priorities to its recommendations and requirements to help authors distinguish what is most important for accessibility.
Player developers should consult the User Agent Accessibility Guidelines ([WAI-USERAGENT) and accompanying techniques document ([WAI-USERAGENT-TECHS]), which explains how to design accessible user agents, including synchronized multimedia players.
Developers of SMIL authoring tools should consult the Authoring Tool Accessibility Guidelines ([WAI-AUTOOLS]).
The SMIL 1.0 attributes discussed in this document are listed here, followed by links to their definitions in the SMIL 1.0 specification.
The following sample has been provided by the CPB/WGBH National Center for Accessible Media (refer to [WGBH]). The presentation contains captions, subtitles and auditory descriptions in English and German. To play the presentation:
Here is a transcript of the presentation:
W3C's Web Accessibility Initiative (WAI) addresses accessibility of the Web through five complementary activities that:
WAI's International Program Office enables partnering of industry, disability organizations, accessibility research organizations, and governments interested in creating an accessible Web. WAI sponsors include the US National Science Foundation and Department of Education's National Institute on Disability and Rehabilitation Research; the European Commission's DG XIII Telematics for Disabled and Elderly Programme; Telematics Applications Programme for Disabled and Elderly; Government of Canada, Industry Canada; IBM, Lotus Development Corporation, and NCR.
Additional information on WAI is available at http://www.w3.org/WAI.
The W3C was created to lead the Web to its full potential by developing common protocols that promote its evolution and ensure its interoperability. It is an international industry consortium jointly run by the MIT Laboratory for Computer Science (LCS) in the USA, the National Institute for Research in Computer Science and Control (INRIA) in France and Keio University in Japan. Services provided by the Consortium include: a repository of information about the World Wide Web for developers and users; reference code implementations to embody and promote standards; and various prototype and sample applications to demonstrate use of new technology. To date, more than 320 organizations are Members of the Consortium. For more information about the World Wide Web Consortium, see http://www.w3.org/
Many people in W3C and WAI have given valuable comments to this document. The authors would like to thank Charles McCathieNevile, Philipp Hoschka, Judy Brewer, Geoff Freed, Madeleine Rothberg, Lloyd Rutledge, and the SYMM Working Group for their contributions.
A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.