Making Multimedia Section 508-Compliant and Accessible

Jun 26, 2013

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 email, 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, we also have 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 conformant (compliant) nor are they accessible. Here are the facts, requirements, and resources for posting media files that your site’s visitors can easily access.

A disabled symbol on a keyboard button

goldy / iStock / Thinkstock

Why We Need Accessibility

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 wasn’t 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 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.

Section 508 Requirements that Apply to Media

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 files, 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:

Make sure your video, animation, or other multimedia product does not contain flashing, strobing, or flickering elements within a frequency greater than 2 Hz and lower than 55 Hz, as they can cause some people to experience seizures, dizziness, and nausea. You can test to see if your content falls in these ranges. See the PEAT Tool from the Trace Center and IBM’s Human Ability and Accessibility Center’s Developer Guidelines.

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.

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 in your content, 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.

For in-depth information on video accessibility, see DigitalGov.gov’s article: Create Section 508-Compliant Videos on Your Government Websites.

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 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:

Section 508’s Functional Performance Criteria, (1194.31), is one of the most overlooked when it comes to new media projects. To gain a clearer understanding of when the functional performance criteria applies, see Section508 Acquisition FAQs about comparable access, section B.2. Briefly, your product must provide comparable access:

  • To people who are blind or have low vision, and/or be usable with assistive technologies for visual impairments;
  • To people who are deaf or hard of hearing, and/or be usable with assistive technologies for hearing impairments;
  • So people with motor disabilities can obtain and use your product; and,
  • So people can use 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 the public uses, and while those sites may not be accessible, agencies may want to use them to provide information and engage with the public. Many federal employees use a practical approach to providing accessible content, by posting videos and presentations on these sites and also posting 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.
  • 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: listen to the links as list (out of their written context, to make sure they make sense), 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 the person speaking uses any acronyms, define them.
  • Watch your video to confirm that the captions are visually clear and not “pixelated,” especially if you’ve used open captions; review the captions for spelling, 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

Resources

General Information:

Developers’ Resources:

Originally posted by Angela Hooker on Jun 26, 2013
Jun 26, 2013