Image and video guidance on GOV.UK recommends that videos are not used to explain concepts or processes. However, there are more than 800 videos embedded on GOV.UK to answer specific user needs. For instance, the videos on how to get Help and support for Self Assessment.
Everything published on GOV.UK, including videos, is created with accessibility in mind. When thinking about how to make a video accessible, you need to think about the 3 parts of a video:
- video content - the footage with image, audio, subtitles and usually an mp4 file
- hosting platform - to play the video the file needs to be stored somewhere, for example on YouTube or Vimeo
- video player - a piece of software that makes the file play and this displays as the controls, for example stop, play or skip
This blog post explains why YouTube was the most suitable video player for GOV.UK. In a future blog post, we will explain more about how to make your video accessible for the YouTube player.
Why we changed our video player
Since 2012, GOV.UK has used the Accessible Media Player by Nomensa. However, the video player has not been maintained since 2015 with GDS making its own changes to the code since then. Accessibility audits and testing with assistive technology also revealed some challenges, as well as reports from people using services. For example, captions could not be switched on or off and it was difficult for some screen reader users to know that there was a video on the page.
After we found this, we had 3 options:
- fix the player and maintain it
- build our own player
- find an alternative player
As we do not work much with videos at GDS, we decided to look for an alternative video player that was more accessible rather than build or maintain one.
Searching for an alternative video player
We wanted to define our acceptance criteria for an accessible video before we searched for an alternative. These were shared with the accessibility cross-government community, a Google group with more than 1,200 members, to add more and give feedback.
Some of the general criteria for video players included:
- working in all screen sizes
- working in all supported browsers
- support videos hosted on YouTube
- actively maintained
- resource-friendly meaning it’s quick to load
Some of the accessibility criteria for video players included:
- interactions must be possible to be operated with keyboard only
- support for switching to British Sign Language (BSL) videos
- capability to have closed captions and/or subtitles and the ability to turn them on and off
- allow for multilingual captions/subtitles
- all elements have sensible accessible names - these let screen reader users have icons, for example, read out sensible descriptions, rather than something vague
Through research in GDS and with the Accessibility community a longlist of 20 alternative video players was created. This list went through 3 testing stages. Firstly, we looked at the broadest and easiest to gather criteria, for example seeing if it supports videos hosted on YouTube. This cut the list to about half its size. Secondly, we did some quick tests like making sure the main functionality works with keyboard only, which filtered out another 5. Then finally we had 5 players which we tested extensively: Plyr, MediaElement.js, Video.js, Able Player and native YouTube player (the one that automatically gets added when you copy code from YouTube).
The results of testing the video players
In this final stage of testing we knew we would not find something that was completely accessible. However, we wanted to find the video player which removed the most barriers to our users.
To assess the 5 video players we did a few manual checks. We tested:
- using keyboard only
- using keyboard only when the video is running in fullscreen mode
- increasing the font size to 200%
- changing colours in Firefox
- changing colours in Windows 10 High Contrast mode
- using NVDA screen reader in Firefox
- using VoiceOver screen reader in Safari on iOS
- using Dragon, a voice control tool
The only videos tested were YouTube videos as we only host YouTube videos on GOV.UK. For this reason, we had to accept any accessibility issues that are inherent to a YouTube video. For 3 of the players, Video.js, Plyr and MediaElement, there was no support for switching captions on or off. This was an important criterion for us as it was a motivation behind switching video players initially, so this left AblePlayer and YouTube player.
AblePlayer was more accessible, but we also considered things other than accessibility, for example how quickly a player loads is quite important for the user experience. AblePlayer depends on the rather big and still popular jQuery JavaScript framework and it does not adapt very well to all screen sizes.
There were some issues across every player, such as none of them work well when you change colours in the browser or system settings. It led to many interactive elements becoming completely invisible. This is a known issue, which I blogged about a few years ago in a blog post called - “How users change colours on websites”.
Considering all of that, we chose the YouTube player over AblePlayer but also fixed some of its accessibility issues, as this blog post will explain later.
We did a full Web Content Accessibility Guidelines (WCAG) audit on the YouTube player, which we will blog about later in 2020.
Making the YouTube player more accessible
Some aspects of the YouTube player you do not have control over, but there are a few things you can do to make it more accessible.
YouTube embeds their videos via an iframe. Iframes are difficult to navigate for screen reader users as to understand what an iframe is about, iframes need to have a “title” attribute on them. For videos, it should give the video title.
A general accessibility issue with lots of video players is that it becomes difficult for screen reader users to know that there is a video in the first place. Some players solve that by adding a visually hidden heading that is read out to screen reader users which says “video player” or similar. With other players you only notice what all of the surrounding elements mean when you chance upon a button that says “play”. And even then you have to guess what it will play.
We’ve solved both these issues by adding the title of the video and the word “(video)” to the “title” attribute of the iframe.
We have implemented this change, and since July 2019 the video player on GOV.UK is the YouTube player.
We’re keen to hear how other organisations choose their video players. Let us know in the comments what your experiences are.
2 comments
Comment by Jonathan Holden posted on
But why do you HOST on YouTube?
Comment by richardmorton posted on
It's more efficient to use a video hosting service than to build one from scratch, especially as our usage is not particularly high. We want to use existing services where possible if they are effective and inexpensive (or in this case free).