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:

    <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>

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">
    <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>

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.

Use font-size: 100% !important

First, I should disclose my bias: I just turned 51, no longer have 20/20 vision, and prefer text that is readable rather than text that makes me squint.

Don't make users squint

Font size in CSS can be specified in any of several size units, the most common of which are pixels (px), em, or %. The differences are clearly explained in Kyle Schaeffer's article CSS Font-Size: em vs. px vs. pt vs. percent.

In his 2006 article The 100% Easy-2-Read Standard, Oliver Reichenstein argued convincingly for using a font-size of 100%, which is the text size browsers use by default.

In 2011 D Bnonn Tennant's Smashing Magazine article 16 Pixels: For Body Copy. Anything Less Is A Costly Mistake expanded on Reichenstein's article and argued for using fonts that are at least 16 pixels, which is the default size in most browsers.

I don't know this for sure, but I like to believe that browser makers at some point in their histories did extensive usability testing to determine the optimum font size to use as their factory default setting. So I agree with Tennant that web pages should honor that standard. But there's a fundamental difference in Tennant's and Reichenstein's recommendations. Tennant is recommending 16 pixels, whereas Reichenstein is recommending 100%. For many users, these two units are the same since 16 pixels is the browser default. However, some people change the default font size in their browser. It's easy to do, right there in Preferences where folks can change all sorts of things like their browser's start page and whether to block pop-up windows. The screen shot below shows the Preferences dialog in Firefox, where users can select any of an impressive range of font size options, from 9 pixels to 72.

Screen shot of Firefox preferences dialog

When users change their browser's default font size, either larger or smaller, it's because 16 pixels is not the optimum size for that person. They have a personal need or preference for text in a different size.

Continue reading

Crashing at the College Inn, Lost In Time

In 1992, DO-IT was founded with funding from the National Science Foundation, and every year since then has hosted a Summer Study program in which high school students with disabilities spend two weeks on the UW campus staying in dorms, learning about college life, participating in workshops and going on field trips that expose them to exciting and challenging academic and career opportunities. Yesterday another Summer Study in this longstanding tradition came to an end.

The kids who participated in this year's Summer Study weren't even born when this program began. For them, 1992 was a very, very long time ago. For me, I was already an adult by 1992, married and on my way to being somewhat comfortably established, already in my second position after attaining a university degree. But I too am a youngster, humbled by the size and history of my university, where brilliant people have worked together to make important discoveries and solve great problems since 1861. Each day at Summer Study I stroll across Red Square in the crisp air of early morning, and behold the majesty of the UW campus. Suzzallo Library stands Cathedral-like, preserving and protecting centuries of thought, and providing a sacred space where students can not just learn, but be awed by knowledge.

From Red Square on a clear day, the view extends to Mount Rainier, far more ancient, majestic and powerful than any of man's feeble creations. The Mountain puts all of this in perspective.

During Summer Study I spend my nights at The College Inn, where rooms are available for as little as $60 per night. Built in 1909, the Inn is nearly as old as the University itself. Its dark rooms, creaking floors, and old—if not period—furnishings are constant reminders that visiting scholars have been staying here for over a century.

Continue reading