Practical Accessibility: Making Prerecorded Audio-Only Media Accessible, by Online ADA.
If you’re using audio on your website, whether as ambiance or to communicate information, it’s important to consider the effects audio has on accessibility. What these effects are depends on your purpose for using the audio and how you deploy it.
The first task is to identify your purpose for using audio. A clear sense of that purpose will help you to decide what measures you must include to make the content that includes the audio accessible for the widest range of users.
Decorative audio is audio that is used as a sort of aural decoration for your site to create a particular mood or ambiance. The most important issue to keep in mind with decorative audio is that users may react differently to that audio, and not all of them will enjoy it or find that it enhances their experience of your site. Some users may find the audio distracting. It might make it hard for them to focus on their primary goals and interacting with the site.
For instance, users with visual impairments may be experiencing in your site via a screenreader. If your audio is too loud, those users may have trouble hearing their screenreader, which will make it difficult for them to navigate the site. Other users might have sound sensitivities or a processing disorder that will make it difficult for them to read text when there’s too much noise.
Audio elements are considered primary content audio when the audio elements are communicating contextually relevant information that is not already duplicated by text elements on the page. This category covers any sort of recording from podcasts to speeches to recorded radio programs.
Primary content audio must be made accessible for users who have hearing impairments or processing disorders that prevent them from easily understanding auditory information. It can have the same kinds of problems as decorative audio, but has additional requirements for making the information it communicates accessible to users.
Making your audio media accessible will help a wide range of users with and without disabilities. Most obviously accessible audio media helps users with hearing impairments. those users need accessibility supports to fill in spots where they could not understand the auditory information, or if their impairment is significant enough, need accessibility supports to use the media at all. Accessible audio also helps users who have difficulty processing auditory information. These users may have trouble retaining information that they hear, so having a transcript gives them a way to review the information visually and in their own time.
Accessible audio also helps users who don’t consider themselves as having a disability. Media use in public places is common. Having a transcript for audio media allows users to consume that media when they are in places where they would have trouble hearing audio or in places where they don’t want to play audio out loud.
Working accessibility into your content development process doesn’t have to be a roadblock. Thinking about accessibility early in the planning stages for audio media makes incorporating the necessary supports simpler and often less expensive. If content creators draft out the audio elements and text first, that text can be used as the foundation for a transcript. If the audio doesn’t have a set script, planning the time and resources to create a transcription during the development process will make it easier to anticipate how accessibility will affect the timeline and cost.
The first two steps in making audio content accessible are determining the purpose of the audio and considering user needs. After these two steps, there is one more step to complete in the accessibility support cycle: identifying the standards and success criteria that will help you to determine whether or not your audio is actually accessible. For this, we will turn to the Web Content Accessibility Guidelines created by the W3C organization’s Web Accessibility Initiative. “WCAG” for short, these guidelines are an internationally recognized standard that gives us a common set of criteria to use when planning for and evaluating the accessibility of digital tools and content.
Many of the audio related success criteria in WCAG apply to decorative audio. The most important WCAG success criterion that applies to decorative audio is 1.4.2: Audio Control. This success criterion requires that a mechanism to pause or stop the audio is available if that audio plays automatically for more than 3 seconds. Alternatively, a mechanism could be provided that allows users to control the audio volume independently from the system volume. The key to 1.4.2 is that users must be able to customize the audio volume to suit their needs. An important note for success criterion 1.4.2 — It is ideal to never have audio autoplay on page load. Giving users the choice to opt into the page audio is better than forcing them to opt out.
A success criterion that’s closely related to 1.4.2 is 2.4.3: Focus Order. 2.4.3 requires that if a webpage can be navigated sequentially and the navigation sequences affect meeting or operation, focus components receive focus in an order that preserves meeting and operability. This success criterion is relevant because for users to customize their experience of your audio, they need to be able to get to the controls quickly, and without difficulty. Burying the audio controls a dozen focusable items in will make it harder for users experiencing the page through a screenreader to find those controls, simply due to the aural interference of this audio you’ve provided. It’s best to put audio controls early on in the focus order so that hitting the tab key one or two times gets the user to the controls that allow them to lower the volume or stop the sound altogether.
This need for easy access to the controls brings up another success criterion 2.1.1: Keyboard. 2.1.1 simply requires that all functionality be keyboard accessible without requiring specific timings for individual key strokes. This functionality is required unless the specific function of the element relies on the path of the user’s movement, rather than simply on getting to the right end points. Full keyboard functionality is an element that’s critical for visually impaired users who are more likely to rely on keyboard navigation and shortcuts.
Constructing the audio controls correctly, preferably using semantic HTML markup, will ensure that users can find and operate these controls using the keyboard. This can be easily accomplished by using an accessible media player or by using native HTML markup to embed the file. Last, label the controls both visibly and programmatically in the HTML markup so that users can easily identify them as the controls for the audio.
Success criterion related to labeling such as 3.3.2: Labels and Instructions, which requires that labels or instructions be provided when content requires user input, and 4.1.2: Name, Roll, Value, which requires that all user interface components, including but not limited to form elements, links, and components generated by scripts, have a programmatically determined name and role that states properties and values that can be set by the user can be programmatically set, and that notification of changes to these items is available to user agents, including assistive technologies.
3.3.2 and 4.1.2 are important because users who rely on assistive technologies, such as screenreaders and voice recognition, need to be able to identify controls via the names of those controls, even outside of the immediate context.
Clear labels or names coupled with appropriate roles for the purpose will make that easier. Screenreaders such as Jaws, NVDA, and Voice-Over, actually read off labels for controls, but default to generics like “button” if there’s no accessible label. Users who rely on voice commands also need clear labels so that they can verbally name the correct control. Specific labels that make it easier for users to identify the purpose of a controller form field will make navigation much simpler for these users.
Roles are important because users will expect different functionality for elements depending on whether that element is a link, button, checkbox, etc. Ensuring that the role matches the functionality helps users to predict what will happen when they use a particular control.
When the audio is primary content, all of the success criterion mentioned previously must be addressed. Audio controls, focus order, keyboard functionality, clear labels, and appropriate roles. In addition, there is one more success criterion to account for: 1.2.1: Audio-Only and Video-Only, Prerecorded.
1.2.1 requires that information communicated through audio must be available to all users, which means providing alternative media versions that contain equivalent information to users who have hearing impairments or difficulty processing aural information. A transcript is the simplest way to accomplish this.
Transcripts can be static text, links to text, or text with an auto scroll option. At a minimum, the transcript must contain all speech included in the audio element with labels that make clear who is speaking. If the media includes sounds that add context and information, for instance the sound of a door opening in a radio play, the transcript should also contain descriptions of those other sounds in what is known as a “descriptive transcript.”
If you have a prewritten script for your audio media, creating a transcript is easy. Just start with that script, check to ensure that it matches the actual audio and contains all important auditory information, and include it on the same page as the audio file as text or a linked page, either just before or just after the audio. If there is no script, the audio will have to be transcribed, but planning that into your process will ensure that the costs and times needed to create the transcription can be factored in from the start.
In the end, while including audio media does require more effort than just embedding the file on your page, a little planning goes a long way toward making accessibility simple. Give users control over the audio, clearly and programmatically label audio controls and make them easy to find, and include an alternative such as a transcript so that all users can get the information contained in the audio.
Incorporating these steps into your content development process removes barriers and gives you access to a larger audience.