In the comments on my previous blog post, Adrian Roselli called me out for my claim that the "menu" design pattern in the W3C's WAI-ARIA Authoring Practices is the right way to code a navigation menu. This is an issue that has plagued me for at least a decade, maybe more. My first blog post on the topic, Accessible Dropdown Menus, was published in March 2012. I followed that up in December 2013 with Accessible Dropdown Menus Revisited, still searching for the holy grail in accessible web navigation menus, but liking what I found in Adobe's Accessible Mega Menu.

Based on these two old blog posts, I've had many people contacting me over the years asking for advice about accessible navigation menus. In recent years, I've always referred them to the WAI-ARIA Authoring Practices. On GitHub, this resource refers to itself as WAI-ARIA: Authoring Practices Guide and is commonly referred to by the acronym APG, so I'll use that here for brevity. The APG contains dozens of design patterns for common web widgets, including a recommended keyboard model and ARIA markup for each. I've always believed that in order to attain a consistent user experience for common widgets across the entire World Wide Web, we need a central source of standard, recommended design patterns; and from my perspective, APG was that source. I have encouraged developers to keep the APG handy, and when they're about to create a widget, check to see if there's a recommended design pattern, and use that. Developers have followed this advice, and when they've wondered how to create a navigation menu (for example), they've gone to the APG, looked for a "menu" design pattern, found exactly what they needed, and simply followed the recipe. However, there's confusion around menus specifically, which has led me to question how zealously I should recommend the APG.

The source of my confusion is that there are actually several design patterns for navigation menus. I'll summarize the three I know about (or four, depending on how you count them):

While watching the Kansas City Chiefs win Super Bowl LIV last night, one of the most effective commercials for me was the one from Squarespace, featuring Winona Ryder sitting roadside in the snow with her laptop. A local law enforcement officer shows up and they have an exchange that's reminiscent of Fargo. The commercial isn't hilarious or outrageous like some of the other commercials, but it's kind of cute, and it sparked my interest. It's actually the only Super Bowl commercial that inspired me to take action: I reached for my phone and went straight to the website Winona had created using Squarespace, WelcomeToWinona.com.

In case you missed the ad, here it is, hosted on YouTube but played within the Able Player WordPress plugin.

Since I visited Winona's site, I now am seeing ads everywhere for Squarespace, as well as for Wix and Weebly. Clearly The Universe thinks I want a website. I don't, but I am curious to know whether these easy-to-use website authoring tools are capable of creating accessible websites. So I created an account on each service, and got started creating some simple websites. Here's what I found...

When HTML5 was published, it introduced the <video> and <audio> elements, as well as the <track> element. The latter provides a standard means of synchronizing text with media for a variety of purposes. The HTML5 spec specifically defines five kinds of track: captions, subtitles, chapters, metadata, and descriptions. The latter is particularly interesting, and is the topic of this post.

Description, historically known as "audio description" or various other terms, is a supplemental narration track designed for people who are unable to see the video. It describes content that is presented visually, and is needed if that content is not otherwise accessible via the program audio. Historically we've outsourced description to professionals, but with prices starting at $15 per video minute, we've never gotten the kind of participation we need if video everywhere is going to be fully accessible.

With HTML5, description can now be written in any text editor. All five finds of tracks, including description, are written in the same file format: WebVTT, which is essentially a time-stamped text file. Imagine that you have a video that beings with a short interview with someone notable, say the president of your university. The president's name and affiliation appears visually in an on-screen graphic but they're never specifically identified in the program audio, so a non-visual person has no idea who's speaking and whether to take them seriously. This is a really simple use case, but common among videos I see in higher education: The video can easily be made accessible by creating a WebVTT file that includes the speaker's name and affiliation, with start and end times indicating when this text should be spoken. There's a bit of thought that must go into timing, as you want to avoid colliding with other important audio, but otherwise it's a really simple task. The result would be a file that looks something like this:

WEBVTT

00:00:05.000 --> 00:00:08.000
Ana Mari Cauce, President,
University of Washington

Save that as a VTT file. Done. Thirty seconds and your video has description.

With text-based description, it's easy to edit the content or the timing (not true if the description narration is mixed into the video). Plus computers can read it themselves; we don't need to hire professional voice actors to do that. This makes description affordable, easy to do for most of the videos we're using in academia, and increases the likelihood that video owners will actually do it.

But how can text-based description be delivered to users?