Accessibility: Screen reader and automatic playing audio collisions

Jul 23, 2021

This is an ongoing issue with many of our courses. When a user with a screen reader navigates to a slide with automatically playing audio, both the audio and the screen reader text to speech play at the same time. Absolute chaos ensues.

We have had to develop work arounds that prevent the audio from autoplaying by setting a variable based on user selection (hidden button - accessible only by tab navigation) at the beginning of the course. Then we have to add more hidden buttons on every slide with audio to allow the screen reader user to play the audio.

Is there any way Articulate could add in a "sniffer" to detect whether the user is using a screen reader and, if so, make ALL audio user controlled by default?

5 Replies
Phil Mayor

When audio plays automatically, one of the requirements of accessibility in particular WCAG is the ability for the user to switch the audio on and off and adjust the volume, at the moment for all courses where full accessibility is required we enable the audio controls on the player. 

Would be nice if these could be accessed via a variable.

Randall Sauchuck

Yes we also have the audio controls enabled. However we don't want to prevent the users with screen readers from ever hearing the audio (mute) as it contains part of the content. We just want to allow them to play it at their action rather than having it auto play over the screen reader TTS. 

Randall Sauchuck

We do have the content as text on screen (or as CC) but in some instances (like a conversation between 2 characters) it is easier to understand the nuances of the content by hearing the actual audio. Those relying on screen readers are sometimes neglected when developing so it would be nice to give them as much of the "full" experience as possible.

Liz Victoria

Detecting whether the learner is using a screen reader isn't a best practice. There are ethical considerations involving privacy. And there are etiquette issues: it's best not to globally remove a feature (audio) without the user's explicit consent.

I do understand and appreciate the intent to give screen reader users a fully equivalent experience. But in the scenario of wanting the screen-read content to be as nuanced as the audio, it's more a matter of careful writing of transcripts or onscreen text to convey the meaning.