Home » Web Content » Accessibility » Making Multimedia Section 508 Compliant and Accessible

Making Multimedia Section 508 Compliant and Accessible

What It Is

You've seen videos, podcasts, and audio files on your favorite sites—whether they're government, private sector, or entertainment sites. These are often viral media: media clips that are wildly popular; are shared through blogs or e-mail; produce chatter on the web; and increase traffic to websites. Some government agencies are using this phenomenon, by participating in the "social web," to further their missions and support the President's mandate for government agencies to be transparent and collaborative with U.S. citizens. However, there's also the challenge of presenting government content in an accessible format. It's no secret that many sites where users post media are not Section 508 compliant nor are they accessible. Here are the facts, requirements, and resources for posting media files that your site's visitors can easily access.

Why It's Important

Imagine, if it isn't an issue for you, that you have severe arthritis and you must use your keyboard instead of your mouse to navigate websites. One day, a friend sends you a link to a must see video on a popular video site, to which you eagerly go … but, because this site hasn't been built with accessibility features, you can't use your keyboard to activate the video player's play, pause, rewind, and volume buttons. Suppose you experience frustration because you can't navigate the site with your screen reader; or you have a cognitive disability and need to read the video's transcript to understand its content; or you're deaf or hard of hearing, and there are no captions on the video, so you don't know what's being said in it.

These are only a few examples of what your users will face if your media files lack accessibility. However, if you plan for accessibility when creating and posting media, you'll find you can create a rich, interactive community where users can get important government information from your agency's official website or blog and dialogue with government.

Specific Requirements

To make the most accessible products, know what Section 508 requirements apply to your media:

Podcasts and other sound files:

Paragraph A, Section 508 1194.22 says, "A text equivalent for every non-text element shall be provided (e.g., via "alt," "longdesc," or in element content)."

If you post podcasts or other audio-only files, such as .mp3's, on your website, you must include text transcripts of these files. You may provide an HTML page containing the transcript or you may link to a separate text file.

If your podcast has video with it (called a "vodcast"), the same requirements for video apply; review the "Videos and multimedia presentations" section below for details.

If you have a background audio track on a web page, it's only necessary to provide a transcript if the track provides content and context to the page. However, it's not recommended to "autoplay" media (to load and automatically play a media file when a web page loads) since it interrupts assistive technologies (AT). Allow your users to choose if they want to listen to the track and provide an on and off button.

A note about text equivalents: If you post videos or a multimedia presentation, only including text transcripts of these files does not fulfill Section 508 requirements; see the section "Videos and multimedia presentations" for help.

Videos and multimedia presentations:

Paragraph B, Section 508 1194.22 requires, "Equivalent alternatives for any multimedia presentation shall be synchronized with the presentation." and

Paragraph C, Section 508 1194.24 also stipulates, "All training and informational video and multimedia productions which support the agency's mission, regardless of format, that contain speech or other audio information necessary for the comprehension of the content, shall be open or closed captioned."

Both of these requirements mean that you must include captions—either open or closed captions—that are synchronized with your video or multimedia presentation. If you have questions on the differences between open and closed captions, see The Difference Between Open and Closed Captioning, from AccessIT, University of Washington.

Paragraph D, Section 508 1194.24 says, "All training and informational video and multimedia productions that support the agency's mission, regardless of format, that contain visual information necessary for the comprehension of the content, shall be audio described."

Along with captioning, if there is visual information—such as action or expressions—in the video that is necessary to understand the production's content, that information must be described in an audio file, which also must be synchronized with the video. This can be accomplished within captioning software. To learn more about audio descriptions, see Joe Clark's Standard Techniques in Audio Description.

According to the U.S. Access Board, these requirements for captions and audio descriptions include live video (see the questions and answers under equivalent alternatives for multimedia presentations). Audio descriptions should be added when posting the video on your agency website.

Paragraph J, Section 508 1194.22: Pages shall be designed to avoid causing the screen to flicker with a frequency greater than 2 Hz and lower than 55 Hz.

Make sure your video, animation, or other multimedia product does not contain flashing, strobing, or flickering elements within these frequencies, as they can cause some people to experience seizures, dizziness, and nausea. Graphics that contain certain types of optical illusions can also have the same effect on users. Further, this type of flashing and movement can be distracting for some users with cognitive disabilities. For more background, see WebAIM's article on Seizure Disorders, and for examples of this type of content, see the Accessibility Forum's Testbed Archive. Please do not view these examples if you are prone to seizures or illness from flashing and strobing.

Be sure to not use the <blink> and <marquee> tags in your HTML as these are known for causing problems for, and annoyance to, many users.

If you have a media item that contains this type of flashing, strobing, or optical illusions, do not post it. If you find that you're overruled and must post this media, include a warning on your web page and do not automatically play the media or show the graphic when your page loads—allow your users to start and stop the media or click to access the graphic if they want to view it.

The screen flicker requirement is somewhat difficult to test; however, there are resources available from the Trace Center, and IBM Human Ability and Accessibility Center's Developer Guidelines.

Software to play videos, audio, and multimedia:

Paragraph M, Section 508 1194.22 states, "When a web page requires that an applet, plug-in or other application be present on the client system to interpret page content, the page must provide a link to a plug-in or applet that complies with 1194.21(a) through (l)."

Modern web browsers often inform users when a missing plug-in is needed to access special content on a web page; however, with the many new devices and "user agents" available, it's still best to provide a link to the required software (such as QuickTime, Flash, Real, etc.) on the page where your media is located.

The software to which you link must also fulfill Section 508 requirements for software as outlined in Section 508 1194.21, Software Applications and Operating Systems. Briefly, the requirements from this section are that the software must:

  • Be navigable using a keyboard;
  • Not interfere with accessibility features of other software or the operating system;
  • Provide an on-screen indication of the current focus (the currently selected place of action);
  • Provide information about the roles, states, and operation of each interface element to assistive technology;
  • Use meanings consistently for any images that identify the software's controls, status, or program elements;
  • Use the operating system to display text and contextual information;
  • Not override any user defined display settings in the operating system;
  • Give users the choice of turning off animations and displaying information from the animations in other method;
  • Not rely only on color to prompt users, or provide information or context;
  • Provide a wide variety of color and contrast settings (only if the application allows users to adjust color and contrast);
  • Not cause blinking or flashing at a rate greater than 2 Hz and lower than 55 Hz; and,
  • Ensure that users of AT are able to fully use and navigate through electronic forms, and provide any necessary cues and directions to the AT.

For in-depth information on these requirements, see the U.S. Access Board's guide on 1194.21.

If you've developed a custom player for your media, the same requirements apply—it must meet the requirements in 1194.21. When your custom player is developed, be sure to use commonly used terms for the player's control buttons (for example, play, stop, rewind, pause, volume, mute, captions on, captions off, etc.). Because these terms are read to users of screen readers and refreshable Braille displays, be sure to ask your developer or vendor to add labels to the player's controls.

Comparable access:

Functional Performance Criteria

This portion of the Section 508 guidelines is one of the most overlooked when it comes to web projects. To gain a clearer understanding of when the functional performance criteria (1194.31) is applicable, see Section508 Acquisition FAQs about comparable access, section B.2. Briefly, your product must provide comparable access:

  • To users who are blind or have low vision, and/or be usable with assistive technologies for visual impairments;
  • To users who are deaf or hard of hearing, and/or be usable with assistive technologies for hearing impairments;
  • So users with motor disabilities can obtain and use your product; and,
  • So users can utilize your product without relying on speech.

Posting on non-government sites:

Many agencies are seeking a definitive answer on whether they would violate Section 508 guidelines by posting multimedia content on non-government sites that are inaccessible. For clarification, Section 508, 1194.1, Purpose states, "The purpose of this part is to implement section 508 of the Rehabilitation Act of 1973, as amended (29 U.S.C. 794d). Section 508 requires that when Federal agencies develop, procure, maintain, or use electronic and information technology, Federal employees with disabilities have access to and use of information and data that is comparable to the access and use by Federal employees who are not individuals with disabilities, unless an undue burden would be imposed on the agency. Section 508 also requires that individuals with disabilities, who are members of the public seeking information or services from a Federal agency, have access to and use of information and data that is comparable to that provided to the public who are not individuals with disabilities, unless an undue burden would be imposed on the agency," (emphasis added).

Further, Section 508, 1194.2, Application also says, "Products covered by this part shall comply with all applicable provisions of this part. When developing, procuring, maintaining, or using electronic and information technology, each agency shall ensure that the products comply with the applicable provisions of this part, unless an undue burden would be imposed on the agency," (emphasis added).

This stipulates that agencies should ensure Section 508 compliance whether content is on an agency or public site, and it includes software, sites, and services that are free of charge.

However, there are many social networking sites that are widely used by the public, and may not be fully accessible, but agencies may want to use them to provide information and engage with the public. Many agencies have found that a practical approach to providing accessible content is to post videos and presentations on these sites and also post the same content, in an accessible manner, on their own agency sites.

Tips for Implementing

  • When planning your multimedia project, include development time for adding accessibility features and testing.
  • If your videos will be produced by a vendor, stipulate in your contract that captions and transcripts be included if you don't have the in-house resources to produce them.
  • For your users' convenience, post transcripts (in HTML or a separate text file) of your media on your website. Including a transcript with your video and audio products will be beneficial to your users with cognitive disabilities, who may find a transcript aids in comprehension; to users with low-English/language proficiency, as they may struggle with unfamiliar words; and to non-technical users, if the video contains jargon. The bonus is that it will also help with site indexing and search engine optimization.
  • Instead of embedding media on your page, provide a link to a standalone media player. This provides increased accessibility. (See Media Player Accessibility from WebAIM for background information.)
  • Rather than setting videos and other multimedia with sound to start playing when your web page loads, allow your users to start the media. Otherwise, the sound will interfere with content read by screen readers and refreshable Braille displays.

Key Areas to Test for Accessibility

This isn't a comprehensive list but these are important items you'll need to check in addition to your general accessibility testing.

  • Use your keyboard to navigate through the multimedia player: Use the tab, enter, and spacebar keys to start, stop, fast forward, rewind, turn on/off captions, maximize/minimize the window, and raise/lower the volume, in addition to any other controls your player uses. When testing with the tab key, be sure the tabbing order makes sense.
  • Use a screen reader to review your pages, media player's controls, etc.: Check all of the items you reviewed with your keyboard, plus listen to any directions and cues; make sure there's nothing like "1 button; 2 button" (make sure the buttons are "labeled" with commonly used terms); listen to the entire page/window: isolate links, open lists of graphics and headings; listen to any synchronized audio description tracks); turn off your monitor while you listen to the screen reader and compare it to a script of the exact content that should be heard from the screen reader.
  • Make sure your transcripts read exactly as the audio from your media; check the transcripts for proper punctuation; and, if any acronyms have been used, define them.
  • Watch your video and check that the captions are visually clear and not "pixelated," especially if open captions have been used; make sure captions have been spell checked and reviewed for proper grammar and punctuation.
  • Ask people with different disabilities to test your media project. Their results in using your media may be different from yours.
  • Document your testing with screen shots, reports from testing tools, etc.

Examples

  • Cal State San Bernardino has videos that are accessible by keyboard and feature closed captions.
  • NASA has an extensive, accessible podcast library and is an excellent business model for podcasting.
  • TeacherTube has a video player interface that is fully navigable by keyboard.
  • The University of Wisconsin offers videos in QuickTime, RealMedia, and Windows Media formats. They also provide transcripts of their videos.

Resources

General Information:

Developers' Resources:

Content Lead: Angela Hooker
Page Reviewed/Updated: October 17, 2011

You are now leaving the HowTo.gov website.


CancelView Link