Media Players


Maximum Accessibility: Making Your Web Site More Usable for Everyone
By John M. Slatin,, Sharron Rush
Table of Contents
Chapter 14.  Accessible Use of Scripts, Applets, and Plug-ins

The most popular media players Apple's QuickTime, RealNetworks' RealPlayer and RealOne, and Microsoft's Windows Media Player are available both as stand-alone desktop applications and as browser plug-ins. These media players address accessibility in different ways and have different strengths and weaknesses; there are even differences between stand-alone and plug-in versions made by the same vendor. So we can't just tell you to use certain plug-ins and stay away from other ones. Instead, we'll try to provide some guidelines and principles you can use when you need to decide what's best for a particular application. In addition to the following discussion, we summarize our comments in Table 14-1.

Of course, a central component of an accessible media player is its ability to display alternative content, such as captions and audio description tracks. Equally important is the degree of device independence that a player provides when enabling user control. Simply said, can the media player support captioning and synchronous audio tracks as we discussed in Chapter 13? Can the user control the player or plug-in using only the keyboard or assistive technology tools? Is the desired behavior consistent across platforms and browsers? The following sections detail what we found.

Table 14-1. Support for Various Accessibility Features Offered by Popular Media Players



Keyboard Access

User Preferences

Screen Reader Access

Synchronization Method

RealOne, stand-alone


Full menu

Captions and/or audio descriptions

None must provide transcript


RealOne, embedded



Captions and/or audio descriptions

None must provide transcript


RealPlayer 8, stand-alone

Windows, Mac,various UNIX

Full menu (some controls not available volume)

Captions or audio descriptions

None must provide transcript


RealPlayer 8, embedded

Windows, Mac, various UNIX


Captions or audio descriptions

None must provide transcript


QuickTime 5, stand-alone

Windows, Macintosh

Partial menu

None must provide separate file

None must provide transcript

Separate file/partial SMIL

QuickTime 5, embedded

Windows, Macintosh

Full menu

None must provide separate file

None must provide transcript

Separate file/partial SMIL

Microsoft Windows Media Player XP, stand-alone


Full menu


None must provide transcript


Microsoft Windows Media Player XP, embedded


Partial menu


None must provide transcript


Microsoft Windows Media Player 7.1, stand-alone

Windows, Macintosh (most functionality), Solaris

Full menu


None must provide transcript


Microsoft Windows Media Player 7.1, embedded

Windows, Macin- tosh (most func- tionality), Solaris

None if implemented in separate window


None must provide transcript


Flash 5


Can tab in but not out

None author dependent

None must provide transcript


Flash MX/Flash 6.0


Can tab in butnot out

None author dependent

MSAA compliant (Window-Eyes)


Abbreviations: ASX, Advanced Streaming Format XML Redirector; MSAA, Microsoft Active Accessibility; SAMI, Synchronized Accessible Media Interchange; SMIL, Synchronized Multimedia Integration Language.

Caution: Captions Are Not Text Alternatives

The Real players, QuickTime, and Windows Media Player all support closed captions testimony to the success of the technique in broadcast television. It is very important to note, however, that the caption track displayed on the screen is not available to assistive technology devices as text. It is, in fact, more like an image file. This means that screen readers cannot read the caption track. At first glance, this may not seem important since someone using a screen reader will hear the audio track. Some users of the Internet have hearing as well as visual impairments, however, as Helen Keller did many years ago. People who are deaf-blind or have low vision as well as little or no hearing often employ refreshable Braille displays; some users who are blind prefer refreshable Braille devices as well. Like people who prefer synthetic speech (or who don't read Braille well enough to keep up with the refreshable display), these individuals generally use screen readers like JAWS and Window-Eyes, which are capable of converting onscreen text into both Braille and synthetic speech. Since deaf-blind users and others with visual and hearing impairments can neither see nor hear the captions, it is important to provide an additional text transcript for all video and audio elements, as the ATSTAR curriculum described in Chapter 13 does. Unlike the caption track, the transcript can be rendered as Braille.

Media player technology is one of the most rapidly changing elements of the Web. With the advent of recommendations and standards like UAAG and increased support for SMIL, we can expect that multimedia accessibility will continue to improve. Product descriptions and techniques presented in this chapter are likely to have evolved somewhat even by the time you read this chapter. However, the principles that we urge you to bear in mind when selecting media applications remain the same:

  • Device-independence.

  • Predictability of function (across browsers, operating systems, assistive technologies, and player versions).

  • Integrated support for caption text, audio descriptions, and synchronization.

  • User ability to control the interface and presentation.

Consider these principles as we examine the functions of the various media players and the Flash plug-in.

RealNetworks' RealOne

RealOne is the latest version of RealNetworks' media player. The Real players are available for Microsoft Internet Explorer and Netscape Navigator on Windows and Macintosh operating systems, as well as several flavors of UNIX. The stand-alone version of RealOne offers increased accessibility and increased user control of the way content is presented. The menu now includes options that allow users to increase and decrease volume and to display closed captions and audio descriptions simultaneously (previous versions forced a choice between them). The application menus are accessible by many assistive technology tools. In addition, RealOne includes many keyboard shortcuts to control the player; these are listed in the application's Help pages.

We get a very different picture, however, when we look at the plugin version of RealOne. The plug-in version of RealOne remains completely inaccessible to keyboard or other assistive technology devices, which means that users will be unable to control the presentation of multimedia materials with anything other than a mouse. Therefore, RealOne or RealPlayer 8 should be considered only if a stand-alone application is absolutely required. This means that these players should not be embedded into Web pages when presenting Real media files.

As we saw in Chapter 13, RealOne does accommodate equivalent alternatives for multimedia content, including both closed captions and audio descriptions, as well as ALT text for graphics and other types of media files. As previously noted, the RealOne player uses SMIL code to synchronize captions and audio descriptions with the video stream. RealOne's support for the SMIL caption switch gives it a clear advantage if disk space is an important consideration. You can provide one version of the multimedia material, including both captions and audio descriptions. Users can then decide whether to view the captions or listen to the descriptions, or both, or neither.

The sample code below illustrates how SMIL is used to establish a presentation layout, define regions for each media element including the RealText caption track and the video stream, and synchronize them with the <par> element. Note that the caption track is preceded by an SMIL <switch> element. The player responds to the caption track if the user preferences for accessibility are set to "show captions."

<smil>  <head>     <meta name="title" content="SMIL Wrapper"/>     <layout>        <root-layout background-color="black"           height="315"           width="325"/>        <region            background-color="black"           top="5"           left="5"           height="240"           width="320"/>        <region            background-color="black"           top="255"           left="5"           height="60"           width="320"/>     </layout>  </head>  <body>     <par>     <!-- VIDEO -->        <video src="/books/3/135/1/html/2/video.mpg" region="videoregion"/>     <!-- CAPTIONS -->        <switch>           <textstream src="/books/3/135/1/html/2/video.rt"              region="textregion"              system-language="en"              system-captions="on"              title="english captions"              alt="english captions"/>        </switch>     </par>  </body>  </smil>

Apple's QuickTime

The QuickTime player is available for the Windows and Macintosh platforms and most of the popular browsers. QuickTime 5 is the most recent version of this media player at the time of this writing.

Apple has been working to improve QuickTime's accessibility, and both the stand-alone and plug-in versions of QuickTime 5 give people with disabilities more control than previous versions did. Keyboard equivalents for most menu functions are available in the standalone version, and the plug-in version has a clear advantage over RealOne in this respect. The QuickTime browser plug-in has useful keyboard shortcuts, as shown in Table 14-2.

QuickTime 5 also supports the presentation of video with synchronized captions and audio descriptions, as we demonstrated in Chapter 13. It is worth reiterating here, however, that QuickTime 5 does not support the SMIL caption switch. This means that if you want to offer your users a choice between versions with and without captions and with and without audio descriptions, you'll have to provide a separate link to each version. RealOne has the advantage here since it allows users to toggle captions and audio descriptions on and off and can provide just one file that includes both options. So you (or your client) will need to decide how important it is to embed the player in the Web document instead of running the player as a stand-alone application.

Table 14-2. Keyboard Controls for the QuickTime Browser Plug-in



Space bar

Start or stop the movie (toggle)

Up arrow

Increase volume

Down arrow

Decrease volume

Right arrow

Step movie forward

Left arrow

Step movie backward

Apple makes very specific recommendations on how to implement the player in the Web page. Apple's QuickTime developer site states:

The <EMBED> tag allows media file types other than those directly supported by the browser to be handled with an external application or plugin. In this case, the external application is QuickTime Player and the plugin is the QuickTime Plugin.

With the release of Internet Explorer 5.5 SP2 and later, you must use an <OBJECT> tag in addition to the <EMBED> tag for your Web pages to be compatible with both Netscape and Internet Explorer on Mac and Windows systems. . . . [3]

[3] From "Embedding QuickTime for Web Delivery." Accessed March 29, 2002, at

An example of how to accessibly embed the QuickTime player on a Web page is illustrated in the ATSTAR video caption example in Chapter 13. The code for that implementation appears below.

<div align="center"><p>  <object title="QuickTime Movie" classid= "clsid:02BF25D5-     8C17-4B23 BC80-D3488ABDDC6B" width="420" height="368"      codebase="" name="vid">  <param name="src" value="file:/// D:/content/">  <param name="AUTOPLAY" value="false">  <param name="CONTROLLER" value="true">  <param name="enablejavascript" value="true">  <embed width="420" height="368" controller="true"      src="/books/3/135/1/html/2/file:///D:/content/"      bgcolor="FFFFFF" border="0" pluginspage="http://"      loop="FALSE" autoplay="FALSE"      enablejavascript="true"   name="vid">  </embed>QuickTime movie</object>  </div><br>  <a tabindex="5" href="javascript:setqfoc()"      hreflang="en"><IMG      src="/books/3/135/1/html/2//images/spacer.gif" width="10" height="10"      alt="Activate QuickTime keyboard controls."         border="0"></a><br>  </p></div>

This code example includes redundant mechanisms for integrating the QuickTime player within the Web page. This is necessary in order to make the player compatible with both Internet Explorer 5.5 and later and with Netscape. A sequence of <param> elements within the <object> element provides details on the location of the source file (the movie to be shown), as well as whether to display the controller (yes), to run the movie automatically (no), and whether to enable JavaScript (yes). The <object> tag also contains code to download the plug-in if it is not installed via an ActiveX install component.

Within the <object> element, the <embed> tag contains parameters for all the same functions in a format Netscape can use. Note that the <embed> element is not valid HTML (it will be flagged as an error by the W3C's HTML Validation Service), but it must be used in order to ensure compatibility with Netscape (which has supported the <embed> tag since Navigator 2.0 in 1995). In this case, if the plug-in is not available, Netscape is directed to Apple's download page. Following the tag that closes the <embed> element is HTML text that will be displayed if the user chooses not to install QuickTime.

There is also a JavaScript that allows users to regain keyboard control of the QuickTime plug-in if they accidentally tab to (or click on) a part of the page outside the area defined by the <object> element. (Technically, when this happens, the QuickTime player "loses focus," so the user will be unable to start or stop the movie or control the volume from the keyboard.)

The JavaScript that "returns focus" to the QuickTime plug-in is referenced by a link attached to a transparent image that isn't visible on the page (its only purpose is to anchor this link). Someone using a screen reader could listen for the ALT text "Activate QuickTime keyboard controls" and understand what to do. However, the link target (that is, what the href attribute points to) is javascript:set-qfoc(). WCAG 1.0 warns against this technique in the explanation that follows Checkpoint 6.3: "For example, ensure that links that trigger scripts work when scripts are turned off or not supported (e.g., do not use "javascript:" as the link target)."

Fortunately, the code shown above includes statements that turn JavaScript on if it isn't already enabled in the browser. As a result, even users who normally disable scripting will be able to regain keyboard control over the QuickTime plug-in unless, of course, they're using a browser like Lynx, which doesn't support JavaScript under any circumstances. (Lynx does not support JavaScript, but it does allow users to display multimedia and other content using the standalone version of the relevant plug-in.)

Microsoft's Windows Media Player

There are several versions of Windows Media Player in release at the time of this writing: 7.1 for most Windows and Mac operating systems, plus separate versions for Windows XP, Mac OS X, and Solaris as well as other versions for consumer devices.

The latest versions of Windows Media Player do offer considerable accessible user control by providing keyboard equivalents for most menu options, including turning captions on and off. The Windows Media Player plug-in is partially accessible in Internet Explorer 6 under Windows XP, but earlier releases are not accessible when the player is embedded in a Web page.

The typical implementation of a SAMI caption file in Microsoft Windows Media Player is to create an ASX metafile that binds the media file and the SAMI text file in an XML-based code format. Users then link directly to this metafile from the Web page. The ASX metafile ensures that older browsers (or those not made by Microsoft) will launch the stand-alone version of Windows Media Player and deliver content to it, rather than downloading the material and trying to open it within the Web page. Here's an example of the code for an ASX metafile that displays multimedia content in Windows Media Player.

<asx version="3.0">  <title>External Caption Test</title>  <entry> <title>Caption Test</title>  <author>Webmaster A</author>  <copyright>2002</copyright>  <ref href="SAMI_test.wmv"/>  </entry>  <entry>  <ref href="SAMI_Demo.smi"/>  </entry>  </asx>

The Macintosh version of Microsoft's Media Player does not support specifying the SAMI file in an ASX multipart reference. This means that Macintosh browsers need a different way to invoke the SAMI file, as shown here:


Microsoft's Windows Media Player for Mac provides syntax for embedding the media player on the Microsoft Developer Network Web site. But there is still a huge installed base of browsers that predate Internet Explorer 6, and we do not recommend embedding the player unless (as with QuickTime) you're willing and able to provide links to media that will run in the stand-alone player as well.

Perhaps the most important drawback of the Windows Media Player is that it does not support audio description in either the stand-alone or the plug-in version. It does enable captioning through Microsoft's SAMI language, which we explored in Chapter 13. Lack of support for a separate audio description is a very serious limitation. If your video files require audio descriptions (see Chapter 13 for discussion of when descriptions are necessary), you can't use the Windows Media Player unless you're willing to provide the same media in either RealOne (RealPlayer) or QuickTime format as well.

Macromedia's Flash

So far, our encounters with Flash have mostly been problematic. Either a user experience was interrupted with a series of alert boxes ask-ing us to install the Flash plug-in, or we were trying to construct usable workarounds to barriers imposed by Flash content. Macromedia released a new version of the Flash Player (version 6.0) in March 2002. Flash 6.0 represents a significant improvement over all previous versions of the Flash player where accessibility is concerned. But as of this writing, the new version works with only one screen reader Window-Eyes and only with the latest version of that program (4.2, just released). JAWS and Home Page Reader do not yet support Flash 6.0. It can be said that Macromedia made a good faith effort in designing to the MSAA standard. In this view, part of the burden of compatibility must fall as well on the makers of JAWS to design software to a common industry standard. Even so, many users still have older versions of Flash on their computers, and it will be some time before developers can be reasonably confident that most users have Flash 6.0 or later. In the meantime, then, it's important to be aware of the accessibility barriers that people with disabilities will encounter when using older versions of the Flash player and to provide alternatives for those instances.

Central to the accessibility barriers that we encounter when we consider the Flash plug-in as Web content is the question of focus. As we've explained previously, an interface element "has the focus" when the next thing the program does will be triggered by the user's interacting with that element. For example, the Submit button on a form "gets focus" when a user tabs to it after filling out the form: if the Submit button has focus, pressing the return key will submit the form. With Flash, it is possible for users to tab into the <object> element that contains the Flash movie and, if the developer has taken pains to support tabbing within the Flash movie a very big if then it will be possible to tab within the Flash movie.

It may even be possible though again, only if the developer has taken considerable care to interact via the keyboard with some elements of the Flash movie. But it is not possible to tab out of the Flash movie, nor is there any other keystroke or combination of keystrokes that will allow you to get out of that particular briar patch once you've strayed into it. This is due to a bug in Internet Explorer that also affects software other than the Flash plug-in. Nevertheless, the only way out is to click the mouse somewhere outside the borders of the movie, which of course requires (1) that you have a mouse and are able to use it, (2) that you can see enough to find another location on the page, and (3) that there is a location on the page that lies outside the Flash movie.

Suppose that the home page of a corporate Web site consists entirely of a Flash movie that acts as a kind of splash screen. The company logo rotates slowly, then comes to rest above the company name. Users can control the movie via the application menu for the Flash plug-in. The options on this menu (Play, Pause, Rewind, and so on) are accessible via the keyboard. The catch, though, is that there's no way to bring that application menu up via the keyboard! Newer keyboards designed expressly for Windows include an application menu key on the right side of the bottom row. Pressing the application menu key, however, brings up the application menu for Internet Explorer, not for Flash. Similarly, pressing Shift-F10 (a standard Windows command) gives the focus to Internet Explorer's main menu bar rather than the Flash menu. So the only way to bring up the Flash menu is to right-click on the screen (that is, click the right mouse button). But even if you're able to do this (there is no right mouse button on the Macintosh mouse), the only thing you can do on this page is to play the movie, or pause it, or rewind it JAWS does not recognize the text on the screen that identifies the company, nor does JAWS recognize any links that may be encoded in the Flash object.

Flash movies may include graphics, text, video, animation, and sound as well as links, all wrapped into one envelope and dropped onto the Web page. People who do not have Flash installed and people with certain disabilities especially visual disabilities often find the envelope empty. Prior to the release of the Flash MX authoring tool and the Flash 6.0 player, there were no readily available ways of making these elements accessible to screen readers and other assistive technology devices. In other words, earlier versions of Flash failed the accessibility test, both as Web content and as user agents designed to render Web content.

This is why it's worth noting again that the situation we've just described is changing. If the user has Flash 6.0 and Window-Eyes 4.2 instead of JAWS or an older version of Flash, Window-Eyes would speak the text on the page and identify any links or buttons. Flash has been extremely useful for people with learning disabilities like dyslexia, who can benefit tremendously from compelling multimedia. Now people with other disabilities and everyone else stand to gain a great deal as Macromedia works to integrate fuller support for

accessibility into future releases of Flash and other products. Meanwhile, since there's still a huge installed base of older Flash players and authoring tools and the content produced by those tools, developers striving for maximum accessibility must include accessibility features not available through the Flash player itself. As we saw in the previous chapter, the workarounds for providing accessible alternative HTML content for Flash movies are not difficult, but they may have uneven or unpredictable results. It is no more acceptable to insist that "You must have Flash to use this site" than it is to require

support for JavaScript (as the 2002 Winter Olympic Games site does). The burden is on the developer to include equivalent content. As our discussion of the 2002 Winter Olympic Games site suggests, it is always necessary to ensure the availability of redundant navigation mechanisms that do not require Flash. Table 14-3 provides a reminder of some of the methods we discussed in Chapter 13. The table suggests ways to provide equivalent content. We suggest that you use these techniques in a nested manner starting at the top of the table. If each time you use one of the Flash attributes in the first column you include equivalent alternatives by means of the corresponding tag or method from the second column, you will improve the accessibility of your Flash content.

Macromedia has begun to make good on its public commitment to accessibility. In the meantime, if you do use Flash in your work, visit the Macromedia Accessibility site at and download the Flash Accessibility Developers Kit. The kit contains source files in four categories audio, text equivalents, keyboard access, and tabbing and an Accessibility HTML Template for publishing Flash movies on the Web. These are new and relatively untested. Before you publish, test for accessibility using assistive technology devices and users with disabilities.

Table 14-3. Techniques for Maximum Flash Accessibility

Flash Presentation Technique

Provide Equivalent Content

Nested <object> elements

At the lowest level



<script> to detect or launch


Adobe's Acrobat Reader

Adobe Systems has also put some money where its mouth is. The current version of Adobe's Acrobat Reader, version 5.0.5, offers significantly improved support for accessibility both as a stand-alone application and as a browser plug-in. Support for accessibility in Acrobat 5.0.5 extends both to the application itself and to the content it renders.

The first indication of the improved support for accessibility in Acrobat Reader 5.0.5 is that user interface elements that can be accessed through menus and dialog boxes can now also be accessed via the keyboard. According to Adobe's documentation, Acrobat Reader 5.0.5 meets many other requirements of the Section 508 Software Applications and Operating Systems standards as well. Adobe's accessibility site,, presents point-for-point tables showing how Acrobat Reader meets (or does not meet) the Section 508 standards for both software and Web content.

Adobe explains that this has been accomplished by rewriting the application to conform with Microsoft's Active Accessibility (MSAA), an API specifically designed to facilitate behind-the-scenes communication between Windows applications and assistive technology devices. (The devices, of course, must also be programmed to take advantage of MSAA; this is true for GW Micro's Window-Eyes as well as Freedom Scientific's JAWS.)

There is at least one exception, however. Oddly, it affects another important accessibility feature required by both the UAAG and the Section 508 Software Applications and Operating Systems standards. Acrobat Reader allows users to choose their own color schemes (using either the Windows system colors or a custom scheme; see Figure 14-3). This meets the UAAG requirements to ensure user control of rendering and to provide configuration and customization options; it also satisfies Section 508's requirements to respect users' prior color choices as well as allowing high-contrast color schemes within the application. But the JAWS screen reader does not recognize the buttons for setting text and background colors, a (presumably accidental) violation of the Section 508 requirement that information about user interface elements must be available to assistive technology devices. This might seem a trivial point since you might reasonably assume that people who are blind simply don't worry about screen colors and therefore wouldn't miss these buttons. But some people with low vision use screen magnifiers together with screen readers, and it's important that these users receive consistent information from all the assistive technology devices they might use.

Figure 14-3. Screen shot of the Accessibility settings dialog in Acrobat Reader 5.0.5. Selected options include "Use custom scheme" for color and "Always, overriding document colors." Buttons for selecting background and text colors are visible on the screen but not recognized by JAWS. Used with permission.


But while it's true that the bug we've just reported may cause real problems for some users, it's equally true that such problems aren't on the same plane as the accessibility problems we've discussed with respect to Flash 5.0 and earlier versions.

PDF documents may contain some multimedia materials, including QuickTime movies and stand-alone audio (.wav) files. Adobe Acrobat 5.0 does not provide direct support for captioning or describing audio or video that is, you can't use Acrobat to add captions or descriptions to existing video or audio files but it will display QuickTime movies that include captions and audio descriptions. Authors can also include transcripts of stand-alone audio files, either as part of the document itself or as links from the document to other PDF or HTML documents. (Kara Pernice Coyne and Jakob Nielsen's Beyond ALT Text, published as a PDF document in 2001, includes audio transcripts in the main document, then provides links to the .wav files for those who want to hear them.)

Acrobat Reader 5.0.5 is a significant advance toward improved accessibility of PDF documents when used in conjunction with the recently developed tagged content, and Adobe deserves credit for that. Let's hope the company keeps moving in this promising direction.


    Maximum Accessibility(c) Making Your Web Site More Usable for Everyone
    Maximum Accessibility: Making Your Web Site More Usable for Everyone: Making Your Web Site More Usable for Everyone
    ISBN: 0201774224
    EAN: 2147483647
    Year: 2002
    Pages: 128

    Similar book on Amazon © 2008-2017.
    If you may any questions please contact us: