The problem

When completing the modules, users felt that it was difficult to complete as there was a lot of reading. In both our feedback forms and our user research session, many users said they would benefit from audio so that they could listen to the training rather than read it. This issue was particularly frustrating for dyslexic users.

Example of a training page without audio

Example of a training page without audio

Our approach

Following the initial feedback from users about adding audio to the training, we needed to understand what they meant by audio.

In a round of research, we asked users what application of audio they would find helpful in the training.

We heard:

  • 4 participants say they'd want an audio button or symbol to indicate there is audio
  • 1 participant wanted to be able to see how long the audio would take
  • 1 participant wanted the ability to speed it up
  • 1 participant wanted the ability to play and pause it
  • 1 participant didn't want it to highlight the words it was reading out

In total, none of the 4 participants we had spoken to had used assistive audio technology before, and 2 weren't aware that they existed- none of the participants in this round of testing had access needs.

Following this, we did a piece of business analysis to understand what audio options were possible for us. We had to consider:

  • cost
  • technical restrictions caused by the current structure of the training and implementation
  • accessibility
  • how easy it would be update over time if the audio needs to change

Once this was complete, we tested 4 different variations of a training page with research participants, including a training page with:

  • no audio (control option)
  • audio instructions which explained to users how to access browser based assistive technology on their device
  • an audio component, on which users can press ‘play’, causing it to read the content on the page using computer-generated audio. - this component included a volume and speed control for the user
  • an audio component, on which users can press ‘play’, causing it to read the content on the page using pre-recorded human audio. - this component included a volume and speed control for the user

Both audio components were built using the built-in HTML 5 browser component without any reskinning. The computerised audio was simulated by using an Mp3 file containing an audio recording of the Microsoft Edge voice option reading the test page.

The audio components were a simulated solution for the purposes of user research testing. The simulation was carried out by using an MP3 file as opposed to dynamically generating the audio via a built-in software solution.

Example of a training page containing audio instructions

Example of a training page containing audio instructions

Example of a training page containing an audio player. This same format was used for both human audio and computer-generated audio

Example of a training page containing an audio player.

Overall, the two audio components tested better than no audio, and audio instructions. This re-validated that users wanted audio in the training and could benefit from it. But it also told us that teaching our users how to use built in assistive technology wouldn’t work for our users, especially when they weren’t familiar with assistive technology.

Furthermore, the computerised audio tested slightly better than the human audio, with 3 preferring the computer-generated audio, and 2 preferring the human audio. Because the computerised audio tested better, and would be faster to produce, we decided that if we were to implement audio, we would use the computerised audio.

Our solution

To address the issue of our users finding the training challenging to complete, we believe that we should implement audio to the training. The audio feature has not been implemented, but we highly recommend progressing with this feature.

Further analysis and development work will be required to source a dynamic software-based solution. Considerations will need to be given to how this solution can operate within a GDS driven environment.

Further user testing would be required to ensure the selected final audio components work well for our users and are accessible.

Next steps

  • Re-test the dynamic software-based audio solution
  • If it tests well, implement the audio into the training
  • Once implemented, continue to monitor feedback on this to see if it could be iterated