Relax, Accessibility is Easy!

I received two ads this week from accessibility-related vendors, one in the mail and one via Facebook on my phone. The one in the mail was from Nuance and was an ad for Dragon Professional, the speech recognition product that enables people to dictate documents and use their computers hands-free. The ad features a very comfortable man in a dress shirt, reclining in a comfortable chair in an all-white office with his hands locked casually behind his head.

Nuance Dragon Professional ad, featuring relaxed man #1

The second ad was from 3Play Media, a company that provides video captioning solutions. Their ad, like the Nuance ad, features a very comfortable man in a dress shirt, reclining in a comfortable chair on the beach with his hands locked casually behind his head, gazing out across a peaceful water/mountain landscape as the sun sets.

3PlayMedia ad, featuring relaxed man #2 with text overlay: RELAX. We're taking care of it.

At first I thought the man pictured in these ads was identical, a stock photo pasted onto two different backdrops. However, on closer inspection I see that the indoor Nuance guy is wearing a light blue dress shirt and a wristwatch, whereas the outdoor 3Play guy is wearing a white dress shirt and no wristwatch. Also the outdoor 3Play guy is extending his right pinky finger ever-so-slightly, not true of the indoor Nuance guy.

In any case, both guys are extremely relaxed. And for both, the reason they're so relaxed is that they're using accessibility-related products.

As someone who works in the accessibility field, creating, deploying, or using solutions just like the ones in these ads, I'm imagining myself now in that same pose. I am that guy, a very comfortable man in a T-shirt, reclining in a comfortable chair with my hands locked casually behind my head, soaking in the warm vibrant hues of the setting sun. On my ad, the overlay says:

RELAX. Everything is accessible.

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


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