In our new series “Ask an Expert”, Chris Leighton, our Technical Lead, explains a common question that is frequently asked.
If you have any questions about all things digital accessibility, drop an email through to helpdesk@accessibility.org.au or connect with us on our Twitter!
Question:
What are the considerations for making audio content accessible, such as podcasts or audio players on websites?
If information is in an audio only podcast and you want it to be shared fairly and equally with all people including people with disability, consider these options.
Is the information also available via any other method?
If yes, is that method an accessible method, like programmatic text? If yes that’s great.
The next item in relation will be, are the two things clearly and well connected? Can someone who doesn’t hear or hear well easily find and access a text version of the audio content? If yes to these two additional considerations, then a high level of web accessibility is likely achieved and a quality user experience (UX) delivered.
If the audio is connected to text that isn’t programmatic and accessible, then a remedy to that inaccessible text will be required.
Items to consider around audio:
Files
If the audio is in a file embedded in a web page or offered from a file server, does it have a name that makes semantic sense to the audience expectations? Even better does it have a name (label) and preamble offering a deeper understanding of the content or its presentation type? It could and it should.
The file could be preceded by a name that explains its content and a preamble that says, ‘audio with captions’ or ‘audio with open captions (open-captions means always visible or burned-in text) or ‘audio with closed captions’ (captions that can be turned on or off, to be visible or invisible). That name could also include a reference to any text or other accessible alternatives to the audio.
Closed captions in some players are often provided by included text files that are time stamped and synchronised with the media components. This part of the more modern and functional ‘all-in-one’ provision for accessible audio.
Players
Is the audio in a file format that has free players available to all operating systems? It would be best if it is as not having the needed player type existing with users or easily available makes the content ‘immediately unavailable’. If an uncommon free player is needed, then including advice on getting access to that player may assist too. You may have seen links to ‘a free PDF reader, Adobe Reader’ when coming across PDFs – that is the same principle in action. Providing a file and giving users assistance to open it and share in its content.
Is the content offered as part of an integrated audio player and not as a file? Is that player an accessible player with controls that are easily available, labelled and compatible with keyboard, touch, voice-control and mouse use? It should be. If not, a remedy may be needed, or an alternative player may be required.
Here are some good players:
HTML5 Player
JW Player
OzPlayer
and the W3C page on audio players.
Similar player considerations should be made if the user is sent away to a different page for the audio, maybe to a streaming platform like Youtube, instead of using a player embedded in your own website.
If wanting to know about your audio experience against a quality standard think about this inexhaustive list of W3C criteria:
Success Criterion 1.2.1 Audio-only and Video-only (Prerecorded)
Success Criterion 1.2.2 Captions (Prerecorded)
Success Criterion 1.2.3 Audio Description or Media Alternative (Prerecorded)
Success Criterion 1.2.6 Sign Language (Prerecorded)
Success Criterion 1.2.7 Extended Audio Description (Prerecorded)