Able Player is a free, open source HTML media player created with accessibility in mind by me, University of Washington technology accessibility specialist Terrill Thompson, and supported in part by AccessComputing. Version 4.0 was released in April and includes three important new features.
First, Able Player now supports Vimeo. For years, Able Player has been capable of playing YouTube videos, but now it can play Vimeo videos as well, with some limitations. For example, a Plus, Pro or Business Vimeo account is required in order to hide Vimeo's default controller. If videos are hosted on a free account, the Vimeo controller and Able Player controller are both shown. Also, Vimeo's captions are built into its playback controls, so if the controls are hidden in favor of using the more accessible Able Player controls, captions are hidden as well. To overcome this limitation, captions must be hosted both on Vimeo (for individuals who access the video there) and on a local web server (for individuals who access the video on a local website with an embedded instance of Able Player).
Second, Able Player now has full support for audio and video playlists. HTML5 has standard markup for adding accessible media to web pages (using <audio> and <video>), including multiple media source files in various formats (using <source>) and creating multiple time-stamped text tracks in WebVTT format (using <track>). Tracks can potentially be provided in various languages, serving any of five purposes (captions, subtitles, chapters, description, and metadata). All of this is made possible with HTML5 for a single audio or video title, but there is no standard markup for connecting all of the necessary components into a full playlist. Able Player 4.0 includes a method for doing exactly that.
Third, Able Player now uses the Web Speech API to read text-based audio description. As noted, HTML5 provides standard markup for associating a time-stamped text file with a video element for the purposes of description. Previously Able Player supported this by exposing the description text at the appropriate times in an Accessible Rich Internet Applications (ARIA) Live Region, which screen readers could announce. However, this method has many drawbacks. For example, some videos don't have enough silent moments to inject audio description. In those cases, a solution is to pause the video while the audio description is read, then resume playback after the description ends. If a screen reader is reading the description text, there is no way for Able Player to know the user's reading speed, therefore no way to know when the screen reader is finished reading the description. In contrast, the Web Speech API has a callback function, which enables Able Player to resume playback when it's finished reading the description. Additional details about using the Web Speech API for this purpose are provided in one of my recent blog posts titled Audio Description using the Web Speech API.
Now that Able Player 4.0 is out, next steps, both actively underway, are to create an Able Player WordPress plugin and an Able Player module for Drupal 8. These tools will make it much easier for content authors to add accessible videos to their web pages, and will increase adoption and enable accessible video to proliferate throughout the web, including in higher education.