1 Why Is Video Important?

Video is now ubiquitous. One third of all online activity is watching video [1], over two-thirds of all internet traffic is video [2] and over half of all video content is accessed via a mobile device [3]. Over 500 million people watch video on Facebook every day [4] – that’s over 100 million hours of video [5]! On YouTube, the numbers are even higher – over 1 billion hours of video are watched every day [6].

2 Video and Accessibility

Web accessibility is about making sure web sites, web applications and mobile apps (including video) are accessible to people with disabilities. The estimate of people with disabilities in the US is approximately 19% of the population – that’s 56.7 million people [7].

Web accessibility of web sites is best achieved by following the Web Content Accessibility Guidelines, Version 2.0 created by the World Wide Web Consortium (W3C). The W3C states that “following these guidelines will make content accessible to a wider range of people with disabilities, including blindness and low vision, deafness and hearing loss, learning disabilities, cognitive limitations, limited movement, speech disabilities, photosensitivity and combinations of these” [8]. The W3C Web Content Accessibility Guidelines, Version 2.0, contain specific techniques for providing accessibility features within video.

Almost everyone understands the need for accessibility features like transcripts, captions and audio descriptions for people with disabilities: these features also are important to people without a disability when viewing video. Over 85% of all Facebook video is viewed without sound [9] – and, if a video has captions, a user is almost twice as likely to finish the video than if it did not have captions [10]. We all know Google is blind and deaf and we see that in revenue as well – videos with transcripts earn 16% more revenue than videos without transcripts [11]. And what has been dubbed the “Broadchurch effect” (due to the strong accents in the BBC drama “Broadchurch”), the BBC found that 80% of people who use captions are not using it for accessibility reasons [12].

To provide accessible video solutions, web site owners must provide a variety of accessibility features. One of the requirements is that the video player itself must be accessible. Lack of accessibility in video players can be the consequence of a number of things, but usually includes inadequate keyboard access, inoperable captions and non-existence of audio descriptions and transcripts.

3 Testing Video Player Accessibility

We tested the following video players: AblePlayer; Acorn; Adobe; AFB; Amazon; AMI Player; Brightcove; Facebook; JW Player; Kaltura; MediaElement; MediaSite; Ooyala; OzPlayer; Panopto; PayPal; Plyr; RAMP; Video.js; Vidyard; Vimeo; Viostream; Wistia; Yahoo; YouTube; and YouTube embed.

We conducted four rounds of testing:

  • Round 1: Desktop testing on Google Chrome, Windows 10;

  • Round 2: User testing with a vision-impaired user using a screen reader;

  • Round 3: Mobile testing on iPhone and Android devices; and

  • Round 4: Mobile testing on an iPad with a Bluetooth keyboard.

We identified certain “show-stoppers” that were failures of the four non-interference clauses in WCAG2: If technologies are used in a way that is not accessibility supported, or if they are used in a non-conforming way, then they do not block the ability of users to access the rest of the page [13].

3.1 Round 1 Testing

Initially we conducted testing on Google Chrome version 61.0.3163 under Windows 10. A series of tests were undertaken including whether the video player supported audio descriptions, whether the transcript was accessible to the keyboard and whether the volume of the player could be modified. Video players were deemed to include show-stoppers if any of the following occurred:

  • Audio plays automatically; unless the user is made aware this is happening or a pause or stop button is provided – failure of WCAG2 Level A Success Criterion 1.4.2: Audio Control);

  • Video contains a keyboard trap (i.e. users cannot escape from the video using the keyboard) – failure of WCAG2 Level A Success Criterion 2.1.2 No Keyboard Trap; and/or

  • Full-screen video contains a reverse keyboard trap (i.e. users cannot escape from full-screen mode using the keyboard) – failure of WCAG2 Level A Success Criterion 2.1.2 No Keyboard Trap.

At the conclusion of Round 1 testing only the following eight video players remained: AblePlayer; JW Player; Kaltura; OzPlayer; Panapto; Plyr; and YouTube embed.

3.2 Round 2 Testing

Experienced vision-impaired users tested the remaining eight video players on the following combinations of screen reader/operating system and browser:

  • JAWS with Windows 10 with: Internet Explorer; FireFox; and Chrome

  • NVDA with Windows 10 with: Internet Explorer; FireFox; Chrome; and Edge

  • VoiceOver with iOS Safari

  • TalkBack with Android Chrome

A series of tests were undertaken including whether the player’s controls were labelled, button status was announced appropriately and fast-forwarding and rewinding was available to the screen reader user. A video player was deemed to include a show-stopper if the video could not be played– not a failure of WCAG2, but deemed a significant failure. Only one video was excluded at the end of this round of testing: Panopto.

3.3 Round 3 Testing

We tested the remaining seven video players Google Pixel 1, Android 8.0, Chrome and iPhone 7+, iOS 10.3.2, Safari. A series of tests were undertaken including whether the mobile video player supported captions and/or audio descriptions, whether the volume of the video player could be modified and whether color contrast was sufficient. A video player was deemed to include a showstopper if any of the following occurred:

  • Video could not be played – not a failure of WCAG2, but deemed a significant failure;

  • Video could not be paused) – failure of WCAG2 Level A Success Criterion 2.2.2 Pause, Stop, Hide; and/or

  • Video crashed the browser – not a failure of WCAG2, but deemed a significant failure.

Three video players: Kaltura, MediaSite and YouTube contained embedded show-stoppers. The remaining four video players were: AblePlayer; JW Player; OzPlayer; and Plyr.

3.4 Round 4 Testing

We tested the remaining four video players on an iPad, iOS 10, Safari, Zagg keyboard. We tested only one task via the keyboard on the iPad: whether the controls could be operated by the keyboard. A video player was deemed to include a showstopper if any of the following occurred:

  • Video could not be played – not a failure of WCAG2, but deemed a significant failure;

  • Video could not be paused – failure of WCAG2 Level A Success Criterion 2.2.2 Pause, Stop, Hide; and/or

  • Video crashed the browser – not a failure of WCAG2, but deemed a significant failure.

Two video players: JW Player and Plyr, contained show-stoppers. The remaining two video players were: AblePlayer; and OzPlayer.

4 Conclusion

This is the third year that this testing has been conducted. As in previous years, AblePlayer and OzPlayer were the only two video players that do not contain show-stoppers. Although we have seen improvements – such as more video players supporting audio descriptions – we have also seen the advent of new show-stoppers such as reverse keyboard traps. For every show-stopper encountered there will be thousands – perhaps hundreds of thousands – of people who cannot watch the video. As one of our screen reader testers said:

“Video is a very important source of information and is a remarkable aspect of our culture now. Blind individuals must not be excluded from access to data provided in video content. You can’t see, but you can understand.”