Case Study: Massachusetts Tackles Streaming Accessibility
When the Massachusetts Department of Revenue needed to make its video program more accessible for the vision- and hearing-impaired, as well as non-English speakers, it took matters into its own hands.
These days, most of us take viewing a web video for granted—find a site, make a click or two, and off we go. Thanks to Flash, it’s all become remarkably easy. For some viewers, though, it’s not quite so simple; accessing web videos can be a difficult—if not impossible—experience for those who have vision or hearing impairments. While current web technology mostly relies on commercial screen readers to synthesize web text into speech, many readers or self-talking browsers are not particularly reliable in enabling impaired users to access a website’s video player or helping them watch a particular video. This problem can be especially acute with videos that begin playing as soon as a page is loaded. Accordingly, many webmasters and video content managers who are concerned with accessibility usually just post a transcript of the video and call it a day.
Having been involved in web video production for more than 3 years, the Massachusetts Department of Revenue (DOR) has always tried to make its videos more accessible to those with disabilities. It is keenly aware, as a state agency, of the need for government sites to make a positive effort to comply with current federal accessibility law—in particular the requirements set forth in the 1998 amendment to the Federal Rehabilitation Act, commonly referred to as section 508, and the web content accessibility guidelines developed by the World Wide Web Consortium (W3C). These guidelines were created to eliminate barriers in information technology, provide new opportunities for people with disabilities, and encourage the development of technologies that help achieve these goals.
With these guidelines in mind, the DOR created a specific goal for its video program: reach as many of its customers as possible by finding a solution that gives the vision- and hearing-impaired a better level of usability and control over the multimedia content on the department’s website. The DOR had other goals as well: improve the ability of its non-English-speaking customers to watch videos; provide a way for its video content to be shared on social networking sites such as Facebook, Digg, and MySpace; and find a media content management system better able to handle the time-consuming front-end video importing, closed-captioning, and posting processes.
After investigating a number of online video publishing solutions such as Brightcove, Vidego, and YouTube, the DOR learned that these video management systems did not possess the accessibility features it was looking for. Moreover, some of these firms were largely video platforms looking to build a marketing base for non-entry-level streaming clients. As none of these private-sector solutions met its goals, the DOR decided to take the initiative and build a content management system (CMS) and accessible video player itself (Figure 1).
Figure 1. The video player is located on the Massachusetts Department of Revenue’s homepage.
After obtaining support from revenue commissioner Navjeet Bal and senior deputy commissioner Jim Reynolds, a small working group was formed within the DOR’s publishing and media services group. The working group included Peter Olejnik, creative director; Alan Sweeney, interactive media developer; and William Grand, an interactive developer. Olejnik took the lead role in developing the media content management system and player while also managing the day-to-day particulars of the project.
After months of programming, design configurations, and trials, the group emerged with a product that met its initial objectives. Although pleased with the results, there are a number of other functionalities—such as "email to a friend," viewer voting capabilities, and improved reporting and metrics—that will be added in the next iteration.
Having explained the genesis of the project, here’s a more in-depth look at both the CMS and video player.
Media Content Management System
In a nutshell, the Media Content Management System (MCMS), built on Adobe’s Air platform, was designed to significantly simplify the front-end video importing, closed-captioning, and posting processes, as well as the maintenance of the player’s video menu. As web content managers, it is important that the DOR be able to quickly perform these tasks and push videos out to its content delivery network (CDN), especially with late-breaking rush productions. To accommodate these needs, the MCMS allows the DOR, through its self-designed Dashboard menu application, to quickly copy and paste video scripts into the media system (Figures 2 and 3). Once pasted, the DOR can do the following:
—Import, rearrange, or remove videos from the menu using a drag-and-drop methodology
—Edit video titles and summaries
—Change the text-to-speech content for its voice response system
—Manage RSS feeds
—Quickly format captions using a frame-timing workflow
—Automatically create multilingual closed captions using Google’s open source translation application
Figure 2. The Dashboard—DOR’s media content management system interface
Figure 3. A media content management system window
The management system and Dashboard are working well and have saved numerous hours of manual captioning and file preparation prior to posting on the DOR’s CDN.
The player’s interface was designed to be user-friendly, like most contemporary rich internet applications. This was important, as a number of users felt that the DOR’s previous player design was a bit confusing. The old player utilized a scrolling menu that only showed five video thumbnails at a time; other video thumbnails were off-screen and were only visible by scrolling. The DOR’s usage metrics consistently showed that these off-screen videos streamed to far fewer viewers because they were not visible. To address that issue, the new player categorizes videos by topic buttons and toggles through one enlarged video thumbnail at a time (Figure 4). This design is also crucial to the functionality of another player feature: the on-demand voice response system.
Figure 4. The video player’s design components