Handling Captions via the YouTube Player API

I rolled out a new version of Able Player over the weekend, and the new version (2.2.1) now supports YouTube captions and subtitles. It was already possible to use Able Player to play YouTube videos, but until now we had relied entirely on YouTube to handle captions on its own, which isn't necessarily intuitive or convenient for users. If a user has turned captions on via the YouTube website, then they get captions in embedded YouTube players for any video that has captions (automated captions don't count). Conversely, if they've turned captions off on YouTube, they won't see captions in an embedded player, even if the video has captions available. This is browser-specific, so it only tracks the user's current caption preference within the current browser.

Ideally, users would have the flexibility to toggle YouTube's captions on and off and change the language of subtitles from any player, not just on the YouTube website. Based on my reading of the YouTube API Reference I hadn't thought it was possible to control captions from an external player, but it turns out the YouTube API has undocumented secrets, which I thought I'd document here to save other developers some headaches.

First, here are some relevant links:

Next, here's what you won't find in the YouTube API documentation...

Continue reading

Comparison of Browsers on HTML5 Video Accessibility: 2015 Update

This is an update to my earlier Comparison of Browsers on HTML5 Video Accessibility, published two years ago. To test browsers, I used the Native HTML5 Media Player test that ships with Able Player. This test page includes an HTML5 <video> element with two <source> elements to ensure cross-browser support, one targeting an MP4 video file and the other targeting a WebM video file. It also includes four kinds of <track> elements: captions, subtitles, descriptions, and chapters.

Browsers tested

  • Internet Explorer 11
  • Firefox 37 (both Windows and Mac)
  • Chrome 41 (both Windows and Mac)
  • Opera 28 (Mac only)
  • Safari 8 (Mac OS X Yosemite)
  • Safari in iOS 8 (iPhone)
  • Chrome on Android 4.3

Screen Readers tested

  • JAWS 16 in IE
  • JAWS 16 and NVDA 2015.1 in Firefox
  • JAWS 16 and ChromeVox 43 in Chrome
  • VoiceOver in Safari (both Mac OS X and iOS)
  • TalkBack in Chrome on Android

Results

Continue reading

Audio Description in Safari and Yosemite?

In this blog post, I have questions, not answers. However, there will hopefully be answers in the Comments section.

Mac OS X version 10.10 (Yosemite) introduced two new potentially cool new features that I'm cautiously excited about.

Potentially Cool Feature #1

In Accessibility Preferences, there is a new tab called "Descriptions". In that tab, there is a single checkbox, "Play video descriptions when available". This option is prefaced by a brief explanation: "Video descriptions provide a spoken description of visual content in media".

I'm excited by this, but unclear exactly what sort of media it acts upon, and what format the descriptions need to be in for my Mac to recognize them.

I think I found the answer on the Yosemite Accessibility Roundup page, under the heading "New Low Vision Features", there's an item in the list "Support for video descriptions in iTunes, QuickTime, etc." I'm assuming then that the descriptions it supports are those documented in the National Center for Accessible Media's 69-page manual on Creating Accessible iTunes U Content (in tagged PDF). Their manual includes a section on creating audio description, a process that calls for recording the descriptive narration as audio then integrating it with the video using Quicktime. I've actually played around with the methods in this manual before, but it's kind of a long, laborious process, and I'm less excited now if that's what this is about.

Given how easy it is for anyone to create a WebVTT file in any text editor (it's just timestamps and blocks of description text, like a caption file), I'm eager to see more support for that among media players, as I think it's an easier sell to get video owners to actually do it.

Since the list item mentioned three paragraphs ago said this feature applies to "iTunes, QuickTimes, etc." I'm still holding out hope that "etc." means Apple supports WebVTT descriptions in HTML5 video. That brings me to...

Potentially Cool Feature #2

Curious as to whether Potentially Cool Feature #1 would work if an HTML5 media player on a web page includes a descriptions track, I opened a web page that does have such a track, the Native HTML5 Media Player test that ships with Able Player, in Safari 8. This test includes four kinds of track elements: captions, subtitles, descriptions, and chapters. Safari's media player includes a cartoon bubble for its captions menu rather than the customary CC button. But before you simply dismiss this as Apple trying to be different, you should know that Apple actually is different: This button doesn't just toggle the captions on and off like the CC button does in every other browser except IE; it triggers a pop-up "Subtitles" menu that includes all caption, subtitle, and descriptions tracks. Selecting any caption or subtitle track switches to that track, which is Cool Feature #1 (not potentially cool, but actually cool (Safari is one of only two browsers to support HTML5 subtitles, the other being IE).

However, I'm still wondering what's supposed to happen if I select the Descriptions track? How does it work? What does it do? Here's what it does not do:

  1. It does not visibly display the descriptions.
  2. It does not self-voice the descriptions.
  3. It does not expose the descriptions for VoiceOver to read, or if it does, VoiceOver isn't reading them.

Like I said, questions without answers. Okay, standing by now for answers in the Comments...

Constant vs Variable Bit Rate MP3 Encoding and Timed Text

HTML5 introduces all sorts of exciting possibilities with timed text that can be synchronized with media. The new <track> element, used in conjunction with <audio> and <video>, makes it possible to add captions, subtitles, descriptions, chapters, and metadata to your media. As a musician I’m particularly interested in the possibilities of synchronizing text with audio, to create (for example) karaoke-style lyrics to accompany my songs (follow the bouncing ball!) I have even cooler ideas than that, but I’m not quite ready to share them yet (please stay tuned).

One problem I discovered however is that the audio file sometimes gets out of sync, especially when users scrub ahead or back. Troubleshooting this has been maddening, but after many attempts to isolate the problem I finally did so: variable bit rate MP3 encoding.

Continue reading

Go to page 22: The JAWS aria-label with digits bug

Some software bugs are more amusing than others. For some reason I find this one to be amusing, perhaps because I discovered it on a Friday afternoon.

My goal was to provide some context for a list of numeric links that appear at the bottom of a pager feature on a web page, for example at the bottom of a page of search results:

A pagination feature,  featuring the number 1, followed by the numbers 2 through 5, each of which are blue underlined links

Typically this might be coded as a list of links, like so:

  <ul>
    <li class="thispage">1</li>
    <li><a href="page2.html">2</a></li>
    <li><a href="page3.html">3</a></li>
    <li><a href="page4.html">4</a></li>
    <li><a href="page5.html">5</a></li>
  </ul>

Screen readers will read this as "link 2", "link 3", "link 4", and "link 5", which in my opinion is not particularly intuitive and needs a bit more explanation.

With this in mind, I thought I would enhance the list with a few accessibility features:

  • Wrap it in a <nav> element with role="navigation" and aria-label="More pages on this topic"
  • Add hidden text "The current page:" as a preface to the number of the current page. This is hidden using the clip method so it's invisible to sighted users but announced to screen reader users.
  • Add aria-label to each link so that it reads "Go to page 2" rather than simply "2".

Here's the revised code:

<nav role="navigation" aria-label="More pages on this topic">
  <ul>
    <li class="thispage"><span class="hidden">Current page:</span>1</li>
    <li><a href="page2.html" aria-label="Go to page 2">2</a></li>
    <li><a href="page3.html" aria-label="Go to page 3">3</a></li>
    <li><a href="page4.html" aria-label="Go to page 4">4</a></li>
    <li><a href="page5.html" aria-label="Go to page 5">5</a></li>
  </ul>
</nav>

According to the Text Alternative Computation algorithm in the ARIA spec, the link text should be announced only if there is no value for aria-label or aria-labelledby, so aria-label should work as a replacement for existing link text.

This all works beautifully with NVDA 2014.3 in both IE11 and Firefox 32. It also works beautifully with JAWS in Firefox, but in IE11 JAWS announces both the aria-label and the link text (observed in both JAWS 15 and 16 beta). Not only that, but it concatenates them into a single label, which results in "Go to page 22" rather than "Go to page 2". It continues on in this fashion, with "Go to page 33", "Go to page 44", and so on. The position of the aria-label attribute within the code has no effect.

Here's my test page, which includes a couple of possible temporary solutions until the JAWS bug is fixed (I reported it to Freedom Scientific using the JAWS 16 Beta Report form. The ok-but-not-great solutions I came up with are:

  1. Spell out the page number in aria-label (e.g., "Go to page two"). This is an improvement, but JAWS still reads both aria-label and link text so the result is "Go to page two 2". At least that's more accurate than "Go to page 22", but still odd and potentially confusing.
  2. Add additional text to the aria-label to serve as a separator between the two digits, for example "Go to page 2 now". With this approach, JAWS announces "Go to page 2 now 2". Still not perfect, but to me this seems like the best solution until the JAWS bug is fixed.