Terrill Thompson

A Behind-the-Scenes Peek at Automatic Captions on YouTube

noreply@blogger.com (Terrill Thompson) — Fri, 08 Jan 2010 22:19:00 +0000

On November 19, 2009 Google announced that it was launching automatic captions in YouTube. The University of Washington recently joined the list of early testers of this feature, so I thought I'd offer a sneak peek of how it works.

The typical YouTube video player has a button in the lower right corner that for a while now has allowed users, by hovering with a mouse, to turn on captions or to automatically translate captions into any of nearly 50 supported languages. Both of these features obviously depend on the video being captioned. (Unfortunately, that button in the lower right corner does require a mouse - it can't be triggered at all by keyboard alone in any browser).

What's new is that this same button (on select videos in select channels) now includes an option to "Transcribe Audio". If you select that option, Google will do its best to automatically transcribe the video. You can sample this yourself with almost any video on the uwhuskies YouTube channel.

What about accuracy, you ask? Well, it's right about where I would expect it to be. It does better with people speaking clearly in high fidelity acoustic environments than it does in every other scenario, and unfortunately most of our videos fall into the latter category. As a result, an interview with a scientist who says "We're projecting sea levels rising on the beach" is translated as "We're protecting seals' right to free speech". Anyone who's ever used Dragon Naturally Speaking or similar products knows that speech recognition technology can produce some very interesting results.

The hope here is that with massive amounts of new data coming in, Google's speech recognition technology will improve over time. However, my hunch is that in order to learn from its mistakes, Google needs to know which words it has translated inaccurately, and how those words or phrases should have been translated. For this to happen, I suspect that we users need to diligently edit the automated captions, and upload them back to Google. By doing this, we'll be helping to accelerate the viability of the service, and, if the automated caption is accurate at all, we'll be able to edit those and get actual usable captions more quickly than if we were to transcribe our videos manually from scratch.

On the administrative side, when logged in to your YouTube account, if your account supports automatic captioning, you will see a link to "Machine Captions" somewhere within the "Captions and Subtitles" area for a particular video. Selecting that link displays your captions in a grid. Each row of data includes start time, end time, and caption text. When I first saw this, I excitedly thought Google was providing a caption editor, but it currently doesn't actually support direct editing. The data is read-only, and provides a way to quickly navigate the video. By clicking on a caption, the video jumps to that point and starts playing.

Google does, however, provide a "Download" link, which allows account owners to download the machine-generated .sbv caption file, which looks like this:

0:00:06.900,0:00:08.570
My name is on the hill

0:00:08.570,0:00:13.020
I'm a professor of medicine at the technology
and literature and this and that university

This file can then be imported into your favorite captioning tool, edited, and uploaded back to YouTube as the official caption track, replacing the machine-generated caption track.

It's not perfect. We still don't have a quick, easy, and cheap way to accurately transcribe and caption all our videos. But it's a start, and I look forward to keeping an eye on this, and using it, as it matures.

New Years Eve, Prince (The Artist), and Alternate Text

noreply@blogger.com (Terrill Thompson) — Sun, 27 Dec 2009 06:56:00 +0000

Each New Years Eve since 1982, I have found myself humming that defiant yet celebratory New Years anthem by Prince, "1999". This reminds me of something I have often puzzled about, but until now have never blogged about or even mentioned to anyone.

From June 7, 1993 to May 13, 2000, Prince went by the name:

This symbol was said by Prince to be unpronounceable. Therefore, the dilemma: What should we use for alternate text when an image is meaningful, but unpronounceable?

In the above image, I chose to use alt="an unpronounceable symbol". However, I'm not sure if that's the right approach. If sighted users aren't supposed to pronounce the symbol, should screen readers pronounce it? Perhaps a null attribute (alt="") would be more respectful of Prince's intentions, since screen readers don't verbalize images that have null alt attributes.

The authors of the current Prince Wikipedia page chose to forsake the symbol's unpronounceability and used an alt attribute that describes the symbol in considerable detail:

Logo. Hollow circle above downward arrow crossed with a curlicued horn-shaped symbol and then a short bar

That's certainly more informative than silence, but is it meaningful? In my opinion, it's only slightly better than the official ASCII version of the symbol: O(+>

Sighted people may notice that the unpronounceable Prince symbol contains the universal signs for both male and female, united together into one. Some may agree that this union seems to either be celebrating sexuality or androgyny, or perhaps both, which is arguably important information since it's part of Prince's persona and brand. So, we're faced with the challenge of succinctly communicating that symbolism to users who are unable to see the logo, and I don't think the Wikipedia description quite reaches that target. According to the Prince.org Online Fan Community, "the glyph incorporates the male and female signs along with the alchemy symbol for soapstone". Maybe that description should be incorporated into the alternate text for the image.

Interestingly, the official copyright registration of the symbol shows that the symbol actually does have a title, "Love Symbol No. 2". One can imagine that the artist at that time formerly known as Prince probably struggled with this same dilemma that we now face when he was filling out the copyright application for his unpronounceable symbol, and was faced with "Title", which is a required field.

With Prince having set this precedent, I think we're justified in referring to the symbol using some sort of verbiage, and I think we probably should refer to it by it's Prince-given title. Therefore, after this careful analysis I'm now inclined to use alternate text that combines information from Prince himself and from his fan club:

Love Symbol No. 2: a symbol that incorporates the universal male and female signs along with the alchemy symbol for soapstone

Anyone have better suggestions? Just something to ponder this New Years Eve as we party like it's 2009.

My New, More Accessible Blogger Template

noreply@blogger.com (Terrill Thompson) — Wed, 09 Dec 2009 16:08:00 +0000

For those of you who have been reading my blog for a while, you may have noticed that I recently changed my template. This is a Blogger blog, and when I originally set up my Blogger account I was in a hurry to do so and simply selected one of the available templates. However, I've never been quite satisfied with its accessibility. So, after 15 months with this task on my back burner, I finally got around to creating a custom template that improves accessibility. Here's how:

Change from Fixed to Liquid Layout

The original design used a fixed width, set at 740px. This is a common approach to layout and actually demonstrates sensitivity to those who have lower resolution monitors. A higher width would cause users with 780px-wide screens to have to scroll horizontally. However, for users with higher resolutions this design presented a lot of wasted space, and resulted in the feeling of content being squished in the center of the screen.

To improve this, I modified the style sheet so that it now has a liquid layout, and therefore scales well. The content fills 75% of the screen width for all users regardless of resolution or window size, and the sidebar floats right and occupies 23% of the width of the content.

Larger Font Size

The default font size in the original design was too small. In fact, the original style defined font-size on the body as x-small, and various child elements had font-size values that were smaller still (85% of x-small is very small indeed!) Oh sure - users can increase font size on-the-fly with Ctrl + in most Windows browsers, and ⌘ + in most Mac browsers, but all users shouldn't have to do that, and some users aren't aware that it's possible.

My approach to all my sites is to set the default font-size on the body element to 1em. That's the size of the letter "m" in the user's default font setting within their browser, and therefore honors users' preferences, assuming they know how to change the font size in their browser. If they don't know how to do this, then using the default size at least honors users' expectations.

More Color Contrast

Several areas of the page had insufficient color contrast, particularly for visited links in the sidebar. As shown in the following screen shot, a quick check of suspect content with the WAT-C Colour Contrast Analyser revealed foreground/background color differences that were well below those required even for minimum conformance to the Web Content Accessibility Guidelines 2.0.

This problem has been addressed throughout the new design. The main content now uses black text on a white background, and the sidebar uses white text on various darker backgrounds. I don't personally find this any less aesthetically pleasing, and it's a heck of a lot easier for all users to see.

Visible Focus for Keyboard Users

The original design had a few hover effects, where links would change color and/or background color as users hovered over them with the mouse. This was done in CSS like so:

a:hover {

background-color: #ff9; /* yellow highlight */
color: #000;

}

However, :hover only results in this effect for mouse users, and it's arguably even more important for keyboard users (e.g., sighted users with upper mobility impairments, unable to use the mouse but navigating by pressing the tab key). Keyboard users can very easily loose their place on the page unless there are clearly visible navigation queues to show their current focus. This is a simple fix, involving the addition of a couple of pseudo-class selectors to the existing CSS definition:

a:hover, a:focus, a:active {

background-color: #ff9;
color: #000;

}

In a perfect world, all we would need to add is a:focus, which according to the CSS2 spec is supposed to apply while an element has focus. However, Internet Explorer doesn't support this, not even in IE8, but it does support :active so the latter is added as an IE workaround.

Add ARIA landmark roles

As described in my previous blog post, the W3C Accessible Rich Internet Applications 1.0 specification (ARIA) introduces the role attribute, including seven so-called landmark roles that identify specific sections that commonly appear on web pages. Landmark roles allow screen reader users (and eventually all users, once browsers build in support) to quickly jump to specific sections of the page using a single keystroke. For example, users of JAWS 10 and higher can navigate forward through landmarks by pressing semicolon, and backward by pressing shift + semicolon, or they can generate a list of landmarks by pressing Ins + Ctrl + semicolon. My blog template now includes landmark roles that identify the "header", "search", "main", and "contentinfo" (footer) sections of the page. There are also multiple "navigation" landmarks (one each for Previous Posts, Archives, and Links) and a "complementary" landmark for the Twitter Tweets box.

Say No to CAPTCHA

I removed the CAPTCHA requirement (I actually did this early on, but it's worth mentioning here). In Blogger, under Settings > "Show word verification for comments", I selected "No". If "Yes" is selected, users must solve a CAPTCHA (those annoying images containing funky distorted characters) in order to post a comment, which would eliminate the possibility of my receiving comments from blind users or anyone else who can't see or process the CAPTCHA. Google does have an audible alternative that accompanies its CAPTCHAs in some applications, but for some inexcusable reason they haven't implemented that solution in Blogger. If they did, I would reconsider whether to use it or not, but would probably still select "No" because the audible CAPTCHAs are difficult to solve, and CAPTCHAs are still inaccessible to people who are deaf-blind, have cognitive disabilities, or other disabilities that affect folks' ability to process text, especially distorted text. With CAPTCHA turned off, I may be opening myself up to SPAM, but I'm willing to assume that risk rather than slam the door on folks who want to comment on my blog posts. I have also set "Comment Moderation" to "Always" so if I do get spammed, the rest of you aren't burdened by that. So far though, in 15 months of blogging, my comments have only been spammed twice.

Say No To the Blogger NavBar

The Blogger NavBar is placed at the top of Blogger Blogs and provides a search box as well as some other navigational features. Other than the Search box, I haven't found the NavBar to be of any great value, plus (ironically, since this is Google), the search feature isn't reliable.

Other than that, the biggest problem with the Blogger NavBar from my perspective is that it loads in an iframe that yields dozens of HTML validation errors. When balancing that with the benefits it provides (none for me), I had no qualms about getting rid of it. To turn off the Blogger NavBar, simply go to Template > "Edit HTML" > "Change the Blogger NavBar", and select option "Off".

Restore Search

Although I didn't want the Blogger NavBar specifically, I did want search capability. Anything that makes it easier for visitors to find content is a good thing. To restore search, I created a Google Custom Search that not only searches my blog, but also my music site and my Twitter feeds, since all are closely related. Unfortunately these days the code that's generated by Google Custom Search is entirely written in Javascript and does not allow the author to provide a fully accessible HTML form field. Fortunately I had some legacy HTML Google Custom Search code lying around from another site I had created, so I used that, and simply plugged in the new id of my custom search, which is provided by Google. Here's the code I'm using for the search field:

<input type="hidden" name="cx" value="014302487112319215093:97arz-ocq5s"/>
<input type="hidden" name="ie" value="UTF-8"/>
<label for="searchBox">Search Terrill's sites:</label>
<input id="searchBox" style="width: 200px;" name="q" type="text"/>
<input id="searchButton" value="Search!" type="submit"/>

</div>

</form>

</div>

One negative aspect of using Google Custom Search is that ads will display in the search results. Hopefully they're targeted well-enough to be useful rather than annoying.

Add Beauty and Branding

I added a background color gradient. That's mostly an aesthetic addition rather than one related to accessibility, although it does help to create some consistency with my music site, flowtheory.info, which uses the same background. As I build more sites, maybe this will become my signature background.

I also added a custom favicon.ico (previously it was the Blogger "B"), so my site now has a tiny "tt" logo that should show up on browser tabs, favorites, and other places that favicons are used. For the curious and unfamiliar, this is the code I used to do that:

There's obviously a lot of redundancy here, but some browsers support different markup so the redundancy is there to satisfy them all.

It's worth noting that the Blogger template includes the following tag:

<$BlogMetaData$>

This tag, positioned within the <head></head> section of the template, injects several <meta> elements, <link> elements, and some Javascript into the web page. This includes tags that set favicon.ico to the Blogger B, so in order to overwrite those tags, the above custom tags must be added after the <$BlogMetaData$> tag. If browsers encounter conflicting tags, they will use the last tag.

HTML Validation: Still a Problem

The page still doesn't validate. Removing the Blogger NavBar reduced the number of validation errors from 96 to 44, and over half of the remaining errors are generated by the <$BlogMetaData$> tag. Most of these errors are related to special characters in URLs not being properly encoded (i.e., & is not encoded as &). I considered removing that Blogger tag altogether and replicating (and cleaning up) its contents directly in the template. However, this isn't feasible since some of the content in those tags is generated programatically and is dynamic. So for now, I'm reluctantly living with the validation errors, taking some comfort in knowing that Jeffrey Zeldman's templates (e.g., Ms. Moto) have 162 validation errors, far more than mine.

It's worth noting that another validation error results from my including ARIA landmarks in the markup. This is a known and generally accepted problem. ARIA improves accessibility, but as of this writing is not yet an official standard and is not valid (X)HTML. There are many discussions about this, including this one on the iheni blog, as well as a workaround demonstrated by Steve Faulkner. As others have said, validation is important, but if it conflicts with users being able to access the site, the latter is arguably more important.

Suggestions?

If there's anything I can do to improve the site further, especially its accessibility, please share your comments.

Musings on ARIA role="application"

noreply@blogger.com (Terrill Thompson) — Sat, 21 Nov 2009 03:16:00 +0000

The W3C Accessible Rich Internet Applications 1.0 specification (ARIA) is currently in "Last Call". The purpose of ARIA is to provide a means for web authors to explicitly identify roles, states, and properties of interactive user interface components on web pages, thereby making them accessible to users of assistive technologies (AT).

ARIA introduces the role attribute, and defines several dozen roles that can be assigned to this attribute. Seven of these are so-called landmark roles, which identify specific sections that commonly appear on web pages: banner, navigation, search, main, complementary (for sidebars), and contentinfo (for footers). Those of you who were counting may be wondering why I only listed six landmark roles.

That's because the seventh, "application", is fundamentally different. The other six landmarks are useful as targets for AT, such as the popular screen reader JAWS, which jumps directly to the next landmark when users press the semi-colon key. Historically web authors have had to add this functionality themselves using "Skip navigation" and similar links, which jump to defined targets on the same page.

The "application" role is supported in the same way as other landmark roles (for navigation), but it has a much greater role than the others in determining how AT will behave. According to the "application" section of the ARIA spec:

The intent is to hint to the assistive technology to switch its normal browsing mode functionality to one in which they would for an application. User agents have a browse navigation mode where keys, such as up and down arrows, are used to browse the document. This native behavior prevents the use of these keys by a web application.

In other words, when screen readers and other assistive technologies encounter role="application", they're supposed to relinquish control of users' keystrokes to the web application.

This raises some concerns for me:

How will users handle their AT not working as they expect it to?
Will web application developers do a satisfactory job of providing keyboard and non-visual access to their applications, so that the usual AT keystrokes truly aren't necessary?
Will web applications be built using standard keyboard interfaces, so users don't have to memorize a different set of keystrokes for every online application they encounter?

If web authors can't answer Yes to questions 2 and 3, I question whether it's safe for AT to relinquish control.

An Example Web Application

An excellent example web application is QueueMusic (thanks, Jayme Johnson!). This application allows you to "Find music, put it in your queue, and then let it stream." The body element looks like this:

In this application, the web page is divided into three main sections, each corresponding with one of the three steps in the process. Each section has a heading atop it (marked up with <h3>): Song Search, Your Queue, and Now Playing.

In the Song Search section, there is a search field. You enter a search phrase into that field, press Enter, and a list of results appears. If you're a mouse user you can now click any item in the results list and that's added to Your Queue (the middle section of the page). Then, if you click any item in Your Queue it plays in the media player that occupies the Now Playing section.

Here's what happens if you're a screen reader user (specifically, if you're using JAWS 11). The behavior is more-or-less the same whether you're using Firefox 3.5 or Internet Explorer 8:

You launch the page, and immediately JAWS announces "Application Mode On". On most web pages, you would now press "H" to jump through the headings on the page, because this gives you a sense of how the page is organized and structured. You try that on this page, and there are in fact headings on this page that might be beneficial for navigation, but JAWS doesn't respond because you're in Application Mode, so you don't know there are headings and even if you did you couldn't jump to them. Something's amiss here though because usually when there are no headings on a page JAWS tells you this, whereas in this case JAWS isn't doing or saying anything. Curious, you try Insert+F6, which normally brings up a list of headings. Now JAWS says "This feature is only available from within a virtual document, such as a page on the Internet." You curse JAWS, because you know with some certainty that you are in fact visiting a page on the Internet.

You also try Insert + F7, which normally would bring up a list of links from the page. JAWS, however, repeats what it told you a moment ago, and you curse JAWS a second time, this time louder and more profane than the first.

You press "f" to jump to the first form field, but nothing happens. (Even after you've found the form field by other means, this will continue to be a frustration for you because you can't easily get back to the form field to search again).

You eventually discover that you can tab to the search field, and you type in your text and press Enter. This returns a list of results and you're able to navigate down through that list with the down arrow. However, when you find the item you want to add to your queue, pressing Enter doesn't queue it. If you had eyesight, you may or may not guess that right arrow is the key that adds the item to your queue, since your queue is positioned to the right of the results list. Since you're navigating audibly, this spatial relationship is meaningless to you.

Once an item is in your queue, you might think you send that item to the media player using right arrow, since that worked in the previous step and the same spatial logic still applies. Not so though. The Enter key may have failed you in the previous step, but it actually works in this step. If you had read the application Help in the beginning, you would have discovered and memorized the sixteen keystrokes that operate this application, but you didn't do that because the Help link is at the very bottom of the page, and it didn't show up when you pressed Insert+F7 to see a links list. Plus, that's a lot of keystrokes to remember. You use many different web applications each day, and it's unrealistic for you to have to memorize a different set of keystrokes for each one.

Someday you will also know that you can toggle application mode off. When you're in Application Mode in JAWS, Insert + V cycles through Application Mode and Virtual Mode. Currently, Application Mode isn't documented at all within JAWS Help.

What Users Are Saying

It may be too soon to know how users are reacting, or will be reacting, to web applications as defined by ARIA. This is all new enough that it isn't yet in widespread use. I encourage those who are actively working to define the ARIA spec to do usability testing with average AT users. I did find a couple of user comments on-line:

First, there's this post from the JAWS-Users list:

Hi Listers, I'm using Jaws 10 and Vista. Tonight everytime I try to go to Yahoo mail, Jaws says application mode on. I don't have any idea what that means, but I can't navigate the page at all with the PC/virtual cursor. I can read with the Jaws cursor, but when I route PC to Jaws, reading is very strange with Jaws not recognizing links or responding to any commands. I would like to understand what application mode is and how to not have it come on without being asked for.

I dont know what you've done but it messes up JAWS real bad. I checked the 2 examples and somewhere down the page JAWS goes into a mode I've never heard before, applications mode. When it is in this mode I cant navigate anywhere and have to close the page. I'm using JAWS 10.0...

...I have never heard of applications mode, I found it frustrating and if I run into it I'll just close down the page and leave, how many others will do the same?

Conclusion

Despite my being critical in this blog post, I don't necessarily think role="application" is a bad idea. However, all stakeholders need to carefully consider what to do with it. AT makers need to carefully consider the impact on their users, and implement support in a way that makes web applications easier for their users to use, not harder (take note, Freedom: Telling users this feature only works on the Internet is not good implementation). And web authors need to carefully consider whether using role="application" is truly necessary for their site, and if so, they need to be extremely thorough in developing an interface that works well for AT users whose typical interface no longer works. This obviously will require extraordinary attention to detail, and most importantly, plenty of usability testing that includes AT users.

I haven't seen any great resources yet on how to develop web applications that meet these conditions. Section 3.2.6.2 of the WAI-ARIA Best Practices provides some useful guidance, but we need more and better tutorials or I'm afraid we'll just end up with a bunch of bad apps. If folks know of more and better resources, let me know and I'll add them here.

Contemplating Risk

noreply@blogger.com (Terrill Thompson) — Thu, 29 Oct 2009 19:34:00 +0000

I won't bore you with clichés about the relationship between risk and living a full life, but I stumbled across these old photos recently and thought they could express this relationship much better than words.

(Note: These images are described at the bottom of this post, but the description isn't words, it's pictures, rendered non-visually for folks who are unable to see the images).

Boy Contemplating Risk

Later...

Photo Descriptions

The first photo shows my son Noah, age four at the time, seemingly deep in thought as he contemplates the meaning of the large sign that he's standing next to in the forest. The sign reads: "WARNING This area contains hazards associated with water, rocks, and cliff faces. Serious injury or death possible."

The second photo shows my son Noah (and his dad), a short while later, precariously positioned inside a natural window high atop a steep rock face, our faces aglow with satisfaction and accomplishment.

For more about describing pictures for those who can't see them see my earlier blog post on Long Descriptions of Images.

Long Descriptions of Images

noreply@blogger.com (Terrill Thompson) — Sat, 19 Sep 2009 02:59:00 +0000

Yesterday Kyle Weems, aka CSSquirrel (who incidentally I just recently learned is a fellow 'Hamster) discussed in his blog a couple of strategies for adding long descriptions to his comics.

One of the longest-running debates in all of web accessibility is how best to provide long descriptions of images on the web to people who are unable to see them. Most images can be described with an alt attribute, which is read by screen readers whenever an image receives focus. As such, they should be short and sweet, the goal being to ensure that non-visual users have access to the same information that visual users have.

But what if an image can't be described succinctly, such as is the case with a comic strip? In academia, we encounter images like this all the time. Our journal articles, curricula, reports and presentations, etc. are all filled with graphs, charts, diagrams, and figures that are filled with tons of information.

The longdesc attribute has been the standard solution since 1997 when it was introduced in HTML 4.0. Here's how it works: The web author creates a separate web page (e.g., "fig1.html") that contains the long description of the image. Then, they reference that file in the longdesc attribute of the image element:

Unfortunately the web didn't exactly embrace this new attribute. It took many years before screen readers supported it. Freedom Scientific JAWS didn't build in support until four years later with the release of JAWS 4.01 in November 2001. Given the lag time, the workaround that many web developers adopted was a so-called "D link", which was simply the letter "D" in a link adjacent to the image. The D link worked just like longdesc was supposed to (i.e., it targeted a separate web page that contained the long description), but it was supported by all browsers since it was just a link. Although lots of people were aware of this convention there were far more people that were not. I used to practice this technique myself, and I can't count the number of times people asked me "What is that D for?"

Longdesc eventually came around to being supported by the major screen readers, although even today the usability of its implementation is not especially graceful. Both JAWS and Window-Eyes announce to the user that a long description is available (if one is), and prompt the user to read it (if they so desire) by pressing Enter (JAWS) or Alt+Enter (Window-Eyes). So far so good. But if the user responds affirmatively to this prompt, the long description opens in a new window. This has much of the usability baggage that accompanies any link spawning a new window: The user now has multiple tabs or windows to manage; they temporarily lose their focus in the original document; and if they have pop-up blockers enabled the long description may not be delivered at all, even though they've just requested it.

Longdesc also presents a minor inconvenience to web developers, who have extra pages to maintain. Most web developers don't use it, and many that have tried don't use it correctly according to Mark Pilgrim's stats.

All of these might be good reasons to come up with a better method for supporting long descriptions on images. The current draft HTML5 specification has eliminated longdesc, and the WAI CG Task Force on Alternative Text has resolved that it's ok to obsolete longdesc as long as other better methods are in place for providing long descriptions.

That better method is the aria-describedby attribute, which is part of the Accessibility Rich Internet Applications (ARIA) recommendation. Here's the technique for adding a long description using aria-describedby:

Then, somewhere else in the document, add a description with an id matching the one specified in the aria-describedby attribute. The description could be hidden using CSS if desired, but maybe some sighted users would benefit from the description as well.

<p id="fig1">The long description of Figure 1 goes here.</p>

Some long descriptions might be prohibitively long, and really would be better served on a separate page as they currently are with longdesc. For this reason, aria-describedby should support long descriptions that are stored off the page in addition to supporting those that are on the page. That could be accomplished by using aria-describedby to point to the id of a link (as in the following example) as opposed to a paragraph (as in the preceding example, like this:

<img src="figure1.gif"
alt="Figure 1: A bar graph showing accessibility results"
aria-describedby="fig1"/>

<a href="fig1.html" id="fig1">Description of Figure 1</a>

Currently, aria-describedby doesn't seem to be well supported by user agents. I created a Long Description Test Page that includes several images marked up with various combinations of description-related attributes. I tested this page with NVDA 0.6p3.2, JAWS 10, and WindowEyes 7.0 (not the latest version, 7.1) in both Firefox 3.5 and Internet Explorer 8. JAWS and Window-Eyes both handled the longdesc as described earlier, but none of these screen readers announced the aria-describedby description or gave any indication that a description was present. That said, ARIA support in general is moving forward quickly, so I'm optimistic that aria-describedby will ultimately be supported by assistive technologies as well as browsers.

If you experience positive results with aria-describedby on the test page, please post a comment!

Voice Your Support for HR 3101: Make Online Video Accessible

noreply@blogger.com (Terrill Thompson) — Wed, 09 Sep 2009 20:55:00 +0000

While you're contacting your congressperson and encouraging them to support a public health care option, please take a moment to also encourage them to support HR 3101, the "21st Century Communications and Video Accessibility Act of 2009". This bill was introduced by Massachusetts Rep Ed Markey on June 26 and is currently in committee.

If passed, HR 3101 will bring existing federal laws requiring communications and video programming accessibility up to date. As you all know, the Information Age has expanded well beyond our television sets, and we now get information and media from the Internet using our laptop or desktop computers as well as handheld mobile devices.

Back in the days when we got all our information from TV, the Deaf and Hard of Hearing had the same level of access as the Hearing, thanks to federal laws (passed in the 1990s) that required (a) video program distributors to provide closed captions with their programming, and (b) television manufacturers to produce TVs that were capable of displaying those captions.

Fast forward to 2009: You're watching the latest news from CNN on your laptop while catching up on last night's episode of America's Got Talent on your mobile device. This programming is all captioned on television, but not on the Internet, and captions may not even be supported on your mobile device. If you're a person who doesn't have good hearing and therefore needs closed captions, none of this programming is accessible to you. Your only choice for accessing video is to remain in your living room tethered to your TV set.

Worse yet, if you're blind or visually impaired you don't even have equal access to that TV set. You can generally understand most video content based on the spoken dialog and other sound cues, but most programming includes visual content that is not communicated audibly. The art of making this content accessible is called "audio description" (also "video description" and various other terms). It consists of a separate audio track in which a narrator describes key visual content. Blind users can choose to turn this track on or off. This method of providing access to visual content has been around since 1974 (according to this history of audio description), but U.S. telecommunication laws have not required it, and there is little standardization in today's technology as to how it should be delivered.

HR 3101 does for audio description what the federal laws passed in the 90's did for captions. It directs the FCC to conduct an inquiry into the best methods for delivering audio description and to report their findings to Congress within 18 months of enactment of the law. It also requires programs to be described, and requires that video-enabled devices be capable of delivering the descriptions if they're available.

In short, HR 3101 stands to finally bring U.S. accessibility laws related to communications and video programming into the 21st Century. By doing so it will remove the growing array of technological barriers that prevent individuals with disabilities from fully participating in our video-based information society.

To learn more about HR 3101 or to track its progress, one good resource is Coalition of Organizations for Accessible Technology (COAT). Their website includes a One Page Summary of the Bill as well as a Section-by-Section Summary of the Bill.

Free Tools for Captioning YouTube Videos

noreply@blogger.com (Terrill Thompson) — Sun, 02 Aug 2009 19:10:00 +0000

We at the University of Washington are working toward documenting a workflow that would support student interns in adding captions to the university's growing collection of YouTube videos. There are now a dozen or more tools that support the authoring and editing of captions, and over the last couple of weeks I've been exploring several of them. This is a semi-organized set of notes based on my experience with each tool. If others have experiences with these products, please comment!

There are several captioning tools that were not included in the current review, such as MAGpie (Windows and Mac), SubTitle workshop (Windows only), MovCaptioner (Mac only, and not free), the UW-Madison's World Caption (Mac only), and CapScribe, an open source tool developed by the folks at the Adaptive Technology Resource Centre at the University of Toronto.

CapScribe is particularly interesting because it includes a feature that renders audio description using text-to-speech, which I think is an interesting idea worthy of consideration and testing. The desktop version is Mac only, but there is work underway on a web-based version (currently in alpha).

All of these tools produce caption files that can be uploaded to YouTube. However, they don't meet our needs for the current project because we're looking for tools that can work with YouTube files directly, given URLs as input. We're wanting to caption videos that originate in a variety of different formats from dozens of different units at the UW. Acquiring and managing these videos would add a significant amount of overhead to the project. We'd rather just generate a prioritized list of YouTube videos and start captioning. Each of the following tools has that ability:

dotSub
Subtitle Horse
CaptionTube
TubeCaption
Overstream
vSync Bookmarklet
Easy YouTube Caption Creator

dotSub

dotSub is both a tool and a community, providing through its website the means by which people from all over the world can caption (subtitle) videos into various languages. It's the site that has partnered with TED on the TED Open Translation Project.

It accepts as input uploaded videos, or videos on the web, for which it specifically prompts for a direct URL to an FLV file but is able to resolve YouTube URLs. It has keyboard shortcuts that dramatically facilitate the transcription process, which are critical not only for accessibility but for efficiency (see Benchmarks, below). The keyboard shortcuts are conveniently displayed immediately beneath the player window for those who have difficulty committing such things to memory.

The captions show up immediately after they've been entered, so the user can see real time results as they add and edit captions, which is an important feature and not one that's universally available across the products I tested.

One problem is that it doesn't support private videos, which would adversely affect a workflow in which videos were uploaded to YouTube but kept private until they had been captioned.

SubTitle Horse

SubTitle Horse wins the Cutest Logo Award (a child-like, hand-drawn sketch of a horse head). Also, like dotSub, it has an extensive set of shortcut keys available. These shortcuts keys are not as readily available as they are in dotSub, but they're a click away, in the Help menu. Unfortunately the entire application, including the help menu, is built in Flash without much regard for accessibility. As such the list of keyboard shortcuts (a) isn't accessible to screen reader users, and (b) can't be visible on the screen at the same time as the caption editor (it must be closed to resume work). Otherwise, the interface is simple, easy to understand, and provides a complete set of features for meeting my captioning needs.

Unlike dotSub, SubTitle Horse is somehow able to view private videos. I'm not sure if that's a good thing, since it does so without my providing YouTube account information. For the private-until-captioned workflow though, it's a nice feature. Another nice feature is that the video player jumps to the relevant point in the video when you select a caption to edit. dotSub does not appear to have this same functionality.

The greatest weakness of Subtitle Horse may be that it's a single session application. You don't have to create an account, which means your previous work is not saved. The workaround is to export your captions, even if only partially complete, then import them again during your next session.

CaptionTube

CaptionTube is Google's own tool for adding captions to YouTube video. Since Google is so much bigger than everyone else reviewed here, I would expect their product to be hands-down the best. CaptionTube interfaces directly with users' YouTube accounts, so users can easily access and caption their videos. Unfortunately the interaction between YouTube and CaptionTube does not include being able to seamlessly apply the captions once they've been created. That requires exporting the caption file, then uploading it to YouTube in a separate process, just as it does with all the other tools.

As with all the other tools, users can play and caption other users' videos. The instructions prompt users to export the captions and email them to the owner, which I think is good advice.

CaptionTube provides a pair of primary user interfaces (UI's) to choose from: a caption editor with a timeline, and a list of captions. One of these UI's would surely be enough to satisfy most users, but I found both to be confusing and either buggy (meaning the application doesn't work) or unintuitive (meaning I couldn't figure out how to make the application work). The timeline may have potential but since I'm a mouse user with eyesight I expect certain functionality from timelines, like the ability to click and drag to expand or reposition captions on the timeline. Without that functionality, the timeline is purely presentational, and in my opinion more frustrating than useful.

The documentation is inconsistent in reporting the names of buttons and keyboard shorcuts, which ultimately has left me a bit puzzled. There are separate references on the Help page to an "In Time" button and an "End Time" button, which probably are not synonymous, but both are said to have the same keyboard shorcut. Furthermore, I could never get one of these buttons, the button I believe to be the "In Time" (or "Start Time"?) button, to work (I've clicked it in every conceivable situation, and 100% of the time CaptionTube has accused me of wrongdoing).

Also, according to the documentation, CaptionTube has keyboard shortcuts, but I was unable to get any of these to work. They all conflict with common browser or OS keystrokes. For example, Alt + space is supposed to toggle play/pause, but in Windows that combination opens the window's control menu. Clicking various places on the screen to be sure the application has focus prior to trying a documented keyboard shortcut has no effect.

CaptionTube also has a tendency to be slow. After entering a caption, the user must save that caption before going on to the next, and saving sometimes takes a while. I'm not sure whether the bottleneck is on the client or server, but the delays were so significant when I tried using this on a slightly slower laptop that the application was totally unusable, which would seem to argue that it's a client issue. Maybe CaptionTube is optimized for the Chrome browser on the new Chrome OS.

Another shortcoming of CaptionTube, when compared to both dotSub and Subtitle Horse, is that the captions aren't visible on the video while editing. They appear elsewhere in the editor (either on the timeline or in a list), and can be viewed later in Preview mode, but that just isn't the same as seeing the final product and being able to tweak the captions on the fly.

TubeCaption

Before you start accusing TubeCaption of messing with Google's trade name (CaptionTube), you should know that TubeCaption came first. In fact, they've been around for years. Unfortunately I'm not entirely sure what their current status is, but I've included them here just in case they're still alive and well. Their website was working earlier this week, although it wasn't fully functional, but as I publish this blog post I'm seeing signs of trouble even on their home page:

TubeCaption, like dotSub, is/was as much a community as a tool. Their tagline is "We want all web videos to have closed-captions through community efforts" and for a while the community was working hard toward attaining that goal. They could select a YouTube video, caption it, then publish the captioned version for viewing on the TubeCaption site. Their caption editor (called Captionizer) has a long list of attractive-sounding features, including many that I especially value as you may by now know:

A user-friendly interface
Live preview of captions as they're being edited
Keyboard shortcuts

The feature list doesn't include the ability to export, and I suspect that may be a feature resulting from TubeCaption's business model. The site motivates people to caption video by offering them a share of the Google Ad revenue, so of course they would prefer that people view captioned video from their own site rather than go elsewhere. I'm not sure of the legality of embedding YouTube videos for a profit, but I do know that if there's no export option, this is not a tool that will work for our current project at the UW.

Overstream

Overstream is similar to dotSub, but I found it to be slower (I often found myself waiting after clicking a button), and most critically, it has no keyboard interface (see Benchmarks, below.) I played with it for a while but could never get beyond these issues. That's why this review is so stinkin' short.

vSync Bookmarklet

vSync is very simple. The user installs a browser plug-in (in either IE, Firefox, Chrome, or Safari) then visits a YouTube video page. Then, a click on the vSync icon on the browser's toolbar triggers a tool with which the user can enter and submit a transcript. There's nothing here in the way of a transcript editor, so creating the transcript either requires a lot of clicking to and fro to play, pause, and type; or it requires using another tool. Once the user has a transcript and submits it via the plug-in, vSync quickly and automatically converts it into captions and sends the user an email when finished. This process is similar to that of Automatic Sync Technologies (AST), but AST charges for the service, and vSync is free. Before jumping to conclusions though someone should compare the accuracy and quality of the two services.

Once the captions have been automatically generated from the transcript, vSync provides an editor that allows you to tweak them, and unlike CaptionTube it does display the edited captions live in the video player. The editor lacks a few important features (e.g., the ability to insert a new caption) and has a few minor bugs, but these could easily be addressed.

Also of note, vSync provide a handy Caption Converter, which is great if you already have files in one caption format and need to convert them to another format, including SCC (for adding captions to iTunes videos). Being able to convert captions was once more critical than it probably now is for adding captions to YouTube, since originally YouTube only supported captions in SubRip and SubViewer formats. They now support (unofficially) a much broader variety of caption formats, so conversion is less likely to be necessary. However, at my request the vSync folks recently added an offset feature, which is something we need at the UW. We had videos that were already captioned, but when these videos were added to YouTube a brief introductory clip was added to these videos for branding purposes, which meant the timestamps on the captions were no longer accurate. vSync's caption converter allows us to generate a new caption file with caption times adjusted accordingly.

Easy YouTube Caption Creator

This is one of many simple yet handy accessibility-related tools available from Accessify. It's not as feature-rich as any of the other tools described here, nor does it pretend to be.

It simply prompts the user for a link to a YouTube video and a transcript (with line breaks where captions should break). Once the user submits this information, the transcript is presented in a simple caption editor, waiting for the user to timestamp the captions. The user does this by playing the video (by pressing the editor's "Play" button, not the play button on the video player) and pressing the letter a every time they want the next caption to appear.

There are no additional editing tools beyond this, and as such this tool is not likely to meet our needs. However, this tool may be perfect for someone just wanting an easy-to-use interface for generating quick captions without much thought or effort.

Technical Support

All the tools described on this page are free, so it could be argued that you get what you pay for in terms of technical support. However, in some cases you get much more than you pay for. This may not be a fair comparison since I haven't had a need to seek support on each of these tools. However, I did seek support on four of them:

Subtitle Horse: fantastic! I discovered an isolated bug in the video player, contacted support about it using a link on their web site, and had received a live reply within seconds. A few email exchanges later, Björn had found and fixed the problem.
vSync: Awesome! Not only did the vSync folks promptly fix bugs as we spotted them, but they also added an offset feature at our request, and did so within very short order.
Easy YouTube Caption Creator: Outstanding! I experienced a problem that turned out to be a user error, but nevertheless, Ian Lloyd of Accessify was there to help within seconds after I sent an email.
CaptionTube: Ummm... This unfortunately was the lone blemish in my pursuit of technical support. Google's support is offered though the captionTube Google Group, which only has 22 members, and none of the six messages posted since June 18 has received a reply, including my two. More active Google Groups can be very helpful, but this one is clearly not active and no longer seems to be monitored by anyone at Google.

Benchmarks

While reviewing these caption tools, I conducted a test to identify how long it might take for someone like me, with above-average but not lightening-fast typing speed, to transcribe one minute of UW video. I also wanted to test my hypothesis that transcribing/captioning with keyboard shortcuts is significantly more efficient than doing so with mouse clicks.

Method

I selected two UW videos of approximate equal length. Both dealt with the same subject matter (swine flu), and both were "talking head" videos featuring professors who spoke quickly and packed in a lot of content, but were easy to understand. I captioned the first minute of each of these videos, and measured how long it took to attain 100% accuracy and satisfactory synchronization. Prior to starting either test, I practiced with other videos in order to ensure that I was reasonably proficient with both tools.

I captioned the first video with dotSub, and used the available keyboard shortcuts extensively. I captioned the second video with Overstream, which has few if any keyboard shortcuts.

This was not a blind test, and I entered the experiment with a personal bias. However, I sincerely tried in both trials to do my best work and create accurate captions as quickly as possible. Cross my heart.

Results

Time to caption one minute of video using keyboard shortcuts: 8 minutes
Time to caption one minute of video using mouse clicks: 10 minutes

Conclusion

There are many tools available for adding captions to videos! This is great to see. It may suggest that there is a growing demand for captioned video, and with so many products freely available it will hopefully increase the number of individuals and organizations who are actively captioning their videos.

As we at the UW continue to work on adding captions to our small corner of the online video world, I'll keep you posted on our progress. Stay tuned...

Playing with YouTube Captions

noreply@blogger.com (Terrill Thompson) — Fri, 05 Jun 2009 22:43:00 +0000

I've been playing this week with closed captions on YouTube. YouTube announced support for closed captions in August 2008, and followed that announcement with this demonstration video. This inspired us at DO-IT to create our own YouTube Channel and to start uploading captioned videos.

YouTube supports captions in either of two formats, SubViewer (.sub) or SubRip (.srt). The formats are described, with examples, on the YouTube Help page Getting Started: Adding / Editing captions. Until recently I hadn't fully explored YouTube's caption support in any great detail, but here's what I discovered this week:

According to the closest thing I could find to a SubViewer Specification, the SubViewer format includes an optional heading section, which allows authors to control the font family, size, and color of the caption text. These stylistic properties are supported by some media players, but not the YouTube player. I'm actually ok with that, as I think the appearance of captions should be controlled by the user, and commendably YouTube has taken some positive steps in that direction:

To increase text size: press "+" key
TO decrease text size: press "-" key
To change background: press "B" or "b" key

Note that the YouTube player must first have focus before any of these keys work. Therefore, it requires a mouse click (or, in Internet Explorer, the user can tab into the player).

I had similarly little success finding a formal specification for SubRip (the other format supported by YouTube), but according to McPoodle, this format has no head section where universal font styles can be specified, but does support presentational markup within each caption, specifically... um... <font>, <i>, and <b>. YouTube doesn't support this though, and again: I'm ok with that.

Since YouTube gives users control over font size, I find myself questioning whether we should force line breaks in our captions. For example, if a caption includes two short sentences, with a line break at the end of the first, that may be very readable in the default font size, but in a larger font the line break may force the captions to expand onto three lines, with one lonely word on line 2. For the DO-IT videos, we've decided to use line breaks for videos where the user has no control over caption size (e.g., Windows Media and Quicktime), but we remove those line breaks in caption files that will be delivered in players where users do have control, such as the YouTube player.

Keep Your Captions Short

The maximum number of lines that the YouTube caption player will display seems to be three. There also seems to be a limit to the number of characters, as seen in the following example. The example shows a caption in which the word "caption" should appear at the end of line 3, and would easily fit within the width of the video player, but it has been omitted, presumably due to a character limit.

The extra word doesn't show up in a subsequent caption either. In fact, if we added an entire fourth line (I tried this), that line would never show up. However, there seems to be a threshold after which YouTube decides a caption is not just long, but really really long. That's when the player kicks in to a special mode that I call really really long mode. It splits the caption into multiple captions, then displays each caption for intervals of equal length until the next time code from the original caption file rolls around. This is a pretty smart feature, but the fact that it doesn't just do this automatically is a bug. Below is a screen shot of the test video in which I tried to figure out what the threshold was. In the caption on the screen, the word "really" appears six times. There is additional caption text that overflows and is never displayed. I had to add "really" a total of eighteen times before YouTube finally kicked into really really long mode and intelligently displayed the overflow.

Don't Try This at Home

YouTube's really really long mode might have some of you thinking you could just upload a transcript and let YouTube automatically divide it into captions. This, in fact, is true! The only time code that's required is the start time (yes, I tried it). As described in the preceding section, YouTube breaks the transcript into captions and distributes them evenly over the length of the video. This is the same idea that's behind UW-Madison's World Caption with one big difference: after divvying up the captions, World Caption provides an interface that allows users to adjust the captions when they get out of sync. Without making adjustments, the captions and video won't stay synchronized for long and the user who depends on captions is left trying to understand a confusing mess. So, until YouTube can convert your transcript to captions on the fly (using speech processing technology), you'll need to create the captions yourself. There's no reason not to, especially if you already have a transcript since getting the transcript is the hard part. There are plenty of tools and services for converting transcripts to captions, several of which are listed on YouTube's Help With Captions page.

FAWM, RPM Challenge, and Man With Small F

noreply@blogger.com (Terrill Thompson) — Sun, 01 Mar 2009 17:00:00 +0000

Well, I've done it. February may be the shortest month of the annual dozen, but this year it was jam-packed. Among copious other activities, I managed to record 16 new songs and produce an album. I did this along with thousands of other artists around the world who participate on either of two web sites devoted to creating an album in Feburary, fawm.org and RPM Challenge. This is my first year doing this, and I struggled with the decision of which community to join, so I decided to join both. This blog is written in part for others who face a similar quandary, and to clarify some distinctions between the two sites. Let me be clear that I'm not recommending one over the other - just stating the facts as I see them. Both sites make it clear that this isn't a competition, so I want to respect that sentiment in this blog post. My plan here is not to reveal a clear "winner", but is simply to provide information to folks who are wondering how the sites compare.

Initially I thought my participation in the two communities would result in two albums, but halfway through the month I had only recorded three songs and reality began to set in. So with only a few exceptions I posted much of the same material to both sites, and justified that by the fact that (a) there are other folks doing the same thing; and (b) a good scientific comparison demands that I control as many variables as possible.

Man With Small F (The Inaccessible PDF Song)

Before I plunge into comparing the two sites, readers of this blog might be especially interested in this song, which was inspired by a blind university student who came to my office and said "There's something wrong with this document". As it turned out, this was quite an understatement. Of course it's possible to create accessible PDF files. Thanks to Adobe for providing us with the means to make that happen. Unfortunately it requires some awareness on the part of document authors, which was the shortcoming in this case. When I opened the document on my own computer and asked Microsoft Mary to read it aloud, I was impressed with how confidently and dramatically she read utter nonsense. So impressed, in fact, that I went home that night and set it all to music. Check out Man With Small F on my FAWM page.

Now, back to the review...

RPM Challenge

The goal is to produce a CD, with either 10 songs or 35 minutes, whichever comes first. People post their cover art, mail their CD to RPM headquarters, and have discussions about the technical side of CD mastering and production.
In late March, after all CDs have been received at headquarters, there are RPM Challenge listening parties hosting in cities throughout the United States.
In 2009, there were 2229 participants. The community was incredibly responsive. If I would post a question to a discussion board, I would take a couple sips of coffee and wait for a response, and invariably I would have at least one by then, sometimes several.
Songs are hosted by the RPM Challenge website. You upload MP3 files and they're delivered in an embedded media player on each artist's site, as well as in a central Jukebox. There's a 55 MB limit on uploads, which in the end prevented me from uploading all of my songs. Of course, I created six more songs that I needed to, so the overflow ended up being FAWM tunes, which has no limit for reasons explained in the FAWM section.
Participants are identified by zip code, which is nice for getting to know other local participants. At least I imagine it would be nice. Turns out I was the only participant from Bellingham.
Users communicate with each other via blogs and discussion boards. There is no way to comment on particular songs, which is a very nice feature on the FAWM site. As a result, people upload songs then write a separate blog encouraging folks to go listen to their song. This disconnect between songs and discussion is a bit awkward, but people seem to adapt. Nevertheless, I found this to be one of the things I like least about the RPM site.
Musicians with disabilities take heed: The RPM interface is not at all accessible, and has in my opinion some pretty significant usability problems too. There are no "alt" attributes on images, including the main navigation buttons, which essentially renders the site completely unusable for screen reader users. If screen reader users could navigate the site, they would have difficulty navigating individual pages because there are no HTML headings. The site has at least eight nested tables and a distracting background image. They're using JW FLV Player as the embedded media player, which I've praised in previous blog posts for its attention to accessibility. However, JW FLV Player accessibility suffers from some inconsistencies between versions, and RPM is using a version that does not communicate especially well with screen readers.

FAWM.org

The emphasis in this community is on songwriting. You don't produce a CD - you just write 14 songs. That's four more than you have to write on RPM, but it's acceptable just to post lyrics or even a song title, without posting a recording. A few of the participants in fact were lyrics-only writers, but most actually did post complete recordings.
After February, there are no formal community activities such as the listening parties promoted by RPM. Informally, a few of the artists are organizing concerts with other participants from their regions. FAWM does produce a compilation CD each year, featuring some of the best songs from that year. I'm not sure yet how the best songs are determined.
In 2009, there were 2409 participants. Like on RPM, they were very responsive. Each time I posted a new song, I expected immediate feedback, and consistently received that up until the final week when everyone was madly trying to complete their own songs and had less time to listen to others'.
The FAWM website does not host the MP3's. Artists are responsible for hosting them elsewhere, then providing a link to FAWM. Although they're stored off-site, the songs are played directly in an embedded player on the artist's FAWM site, so the interface is seamless. They also partner with a third party to provide free MP3 hosting for those artists who don't otherwise have access to a server. The nice thing about hosting MP3's off site is that I didn't encounter the size limitations that I encountered with RPM. As a result, I not only have 16 songs on FAWM, but one of them is my 7-minute jazz/poetry piece titled Haiku. I couldn't have squeezed that onto the RPM site without sacrificing two other songs.
There is no way to identify participants by zip code on the FAWM site. The closest one can get is identifying them by state. I did find one other Bellinghamster when folks were introducing themselves in a forum.
As noted in the RPM review, one of the features I like best about the FAWM site is the ability to comment directly on individual songs. Each song has its own home page, which includes the song title, a description, lyrics, the embedded player, and user comments. Songs that don't have any comments are flagged as zongs, which alerts diligent participants to listen and comment, the goal being for every song to be heard, and for artists to receive feedback on absolutely everything they produce.
Accessibility of the FAWM site is currently much better than RPM. It has a clean interface and good structural markup throughout, including HTML headings and unordered lists. They use tables for layout in a couple of places, but it's mostly a CSS-based design. Like RPM, they're using the JW FLV Player, and like RPM, it unfortunately isn't the most accessible version. Screen reader users will have to figure out which button is the "Play" button, but fortunately it's a simple player so there aren't many buttons to choose from.

Conclusions

To others: I don't recommend doing both. One thing I've really missed out on by doing this is the other half of communication: Listening. Sure, I can post songs to both sites, but it's a major challenge keeping up with what others are doing in both communities, and community is what it's really all about.

I prefer the FAWM interface, especially the ability to add comments to songs; but I prefer RPM's emphasis on CD production. Ultimately it will probably come down to: Where are my friends? If you read this blog and you plan to do either of the challenges in 2010, let me know. Maybe we can do it together.

There's also the possibility that what I'm describing here only applies to 2009. Both sites are developed and maintained by volunteers, and both sites go into virtual if not actual hibernation during the off season, so maybe nest year they'll both be fully accessible. I posted some accessibility recommendations on the RPM Discussion Board, and according to a moderator we may see "see some big changes in the site over the next eight months, and by 2010... an excellently navigable and intuitive website that really works." Stay tuned...

Contacting the White House with a Screen Reader

noreply@blogger.com (Terrill Thompson) — Tue, 20 Jan 2009 19:38:00 +0000

As excited as I am to see the changing of the guard in the White House, I can't resist pointing out a few significant accessibility problems with the newly unveiled whitehouse.gov website.

The good news: There's a changing of the guard! So I'm hopeful and optimistic that these problems will be fixed. This isn't just blind optimism either. Videos on change.gov were initially not captioned, but the accessibility community raised the transition team's awareness of this issue, and the problem was promptly fixed.

The biggest accessibility problems I see are related to color contrast, particularly in the banner, and keyboard accessibility overall. There's no visible focus other than what's provided by the browser and in most browsers that's so minimal that it's of little value. Mouse users, note how easy it is to select an item from the navigation menu, just by hovering and clicking. Now try accessing these same features without a mouse, just by using the Tab and Enter keys. It's possible, but difficult and not at all efficient. There are lots of mouseless people who are effected by this: People with physical disabilities, people using a stylus, people using speech recognition, etc.

In my opinion, the biggest problem is the Contact Us form, and I'll dwell on that a bit here because it provides a perfect example of why it's important to use accessible markup on forms. It's a pretty straightforward form, with fields for first name, last name, email, address, city, state, zip+4, phone, subject, and message:

The problem with this form is that the labels appear beneath the fields they represent. This in itself wouldn't be a problem if they had used accessible markup. When a screen reader encounters a form field, it first looks to see if there is an HTML <label> element associated with that form field. If there isn't, the screen reader has to guess which label accompanies the field. For sighted users, it's clear that the text positioned immediately beneath a field is the label for that field, but if you strip all positioning away and read the form linearly, that's not so obvious. Most forms have labels before form fields, so that's what screen readers automatically assume. In this case, that erroneous assumption results in the screen reader reading the form incorrectly, which may in turn result in blind citizens either filling the form out incorrectly, or getting confused and not filling it out at all. Here's a summary of what happens when JAWS 9 reads this form (note that the word "Edit" is how JAWS identifies a form field):

For both First and Last Name fields, JAWS reads "Only these fields are required. All other fields are optional Edit"
For the E-Mail field, JAWS reads "Last Name Edit"
For the City field, JAWS reads "Address Edit"
For the first portion of the Zip+4 field, JAWS reads "State Edit"
For the second portion of the Zip+4 field, JAWS reads "Dash Edit"
No labels are read for any of the fields in the right column. JAWS just says either "Edit" or "Combo Box". Most screen reader users can probably figure out the State field since the combo box contains choices. The other fields require significantly more guesswork.
For the Message field, JAWS reads "Subject Edit"

The solution is simple, and again, I suspect it will be implemented soon and this blog post will be obsolete. Here's the current HTML code that's used to implement the First Name field, and the label associated with it. Note that I've stripped out most of the surrounding table tags, as they're not relevant to the point I'm making:

<input type="text" style="width: 192px;" id="ctl05_txtFirstName" maxlength="50" name="ctl05$txtFirstName"/>

<td class="fieldreq" id="ctl05_labeltxtFirstName">First Name</td>

To fix this, simply add a label element informing screen readers that "Last Name" is a label, associated with the form field having id="ctl05_txtFirstName", like this:

<input type="text" style="width: 192px;" id="ctl05_txtFirstName" maxlength="50" name="ctl05$txtFirstName"/>

<td class="fieldreq" id="ctl05_labeltxtFirstName"><label for="ctl05_txtFirstName">First Name</label></td>

Anyone else have feedback (negative or positive) for the Obama web team?

Audio Description and the JW FLV Player

noreply@blogger.com (Terrill Thompson) — Mon, 12 Jan 2009 14:26:00 +0000

Greetings from CALWAC 2009. I'm preparing for a presentation on multimedia accessibility, and figure this seems like as good a time as any to write my fourth in a series of blog posts describing my efforts to create a DO-IT Video Search application that is fully conformant to the World Wide Web Consortium's (W3C) Web Content Accessibility Guidelines.

This installment explores an aspect of multimedia accessibility that receives far too little attention: audio description. When people think about making video accessible, they tend to think about captions for the deaf and hard of hearing. However, video can also be inaccessible to people who are blind or visually impaired. These folks can often get the message of a video solely by listening to it. However, if portions of the content are exclusively communicated visually, these portions are inaccessible. For example, just yesterday I was watching a molecular biology lecture on YouTube, in which the professor was referring to (and pointing to) molecules that he had diagrammed on the blackboard:

This molecule here is able to dissolve certain compounds, whereas this molecule, which has large arrays of these kinds of bonds, is relatively insoluble in water.

In the context of this professor's lecture, you too are blind, and consequently you learned nothing from the above sentence. People who can see the video learn lots about different kinds of molecules.

The best solution with a videotaped lecture is for the lecturer to be sensitive to the fact that not everyone can see their content, and to verbalize it accordingly. In a live lecture, there may be people with poor eyesight who can't see the tiny print on the slides or the scribbles on the blackboard; or there may be people with perfect vision who are disabled by virtue of their seat in the back of the room. A videotaped lecture is no different: There are sure to be some people in the audience who for whatever reason can't see the content visually, so that content should be described.

After the video has been created, if there is still visual content that is not accessible, a separate audio track must be added that describes or narrates the visual content. This is known by various names, including audio description, video description, descriptive narration, and sometimes Descriptive Video Service (DVS), although the latter is a trade name of WGBH in Boston, a leading provider of audio description services.

Audio description is required for conformance to WCAG 2.0 at the most basic level (Level A). It's also required by the Section 508 standards, standards written explicitly for federal agencies who are required by law to ensure accessibility of their information technology resources.

We at DO-IT have always taken two steps toward ensuring the accessibility of our videos for people who can't see them:

We minimize the amount of content that is not described as part of the program audio.
We hire the services of an audio description vendor to add narration where it's required.

We have always delivered our audio description in a separate video. Therefore, we (and our users) have two videos to manage: one with audio description, and one without. In my view, this isn't a perfect scenario. I would rather provide one video for all users, and provide a mechanism by which users can toggle audio description on and off, just like they can closed captions.

That's why I'm excited about JW FLV Player, a Flash player developed by Jeroen Wijering which several versions ago began supporting audio description. The image below shows a snapshot of the JW FLV Player version 3.16. The player controller bar includes both a closed caption button (symbolized by the letter "T") and an audio description button (symbolized by the letter "A"). On a technical level, audio description in this player is very easy to implement. Just create an MP3 file that contains the narration, then pass an audio variable to the player that tells the player that an audio description MP3 file is available and where to find it. Who knew audio description could be so easy? Now everyone should be doing it!

We've done it on a few of our most recent videos, including Equal Access: Universal Design of Computer Labs. Note that in order to watch this video with closed audio description, you will need to select Preferences and check both Audio Description and Closed Audio Description. For your preferred player, select JW FLV Player 3.16 if you want to see the closed caption and audio description toggle buttons as in the above image (no buttons in later versions = a bug that will be fixed soon). Alternatively, select JW FLV Player 4.2 for an improved audio experience (as described below).

There are two major problems with closed audio description:

Foreground vs. Background Volume

Adding audio description by laying an MP3 over the original program audio is an oversimplified solution. Audio description professionals typically remix the program audio, adjusting volumes as needed so the narration can easily be heard over background sounds. Version 4.2 of JW FLV Player introduced the ability to set the volume of the audio description independently of the program audio. This is done when the player is initialized - it can't be adjusted by the user on the fly. However, it's a step in the right direction. Now we can crank the audio description, and turn down the program audio a notch, so the audio description can be heard.

Maybe it's technically possible for the player to listen to the program audio (background) and audio description (foreground) and intelligently adjust these volumes to match a pre-defined ratio between the two. That sounds challenging, but do-able.

Alternatively, a solution that's already possible with the existing player would be to add an audio MP3 that contains the entire program audio remixed with audio description, rather than an MP3 that only contains the audio description. The player could be initialized with this separate audio track set to a high volume, and the original program audio set to 0. This same solution can be used for providing versions of the program translated into alternate languages.

Extended Audio Description

In cases where there isn't enough quiet time in the program audio to insert audio description, the standard practice is to apply extended audio description, a process by which the video is paused briefly and audio description is inserted into the pause. Integrating this functionality into a one-video-for-all-users solution is not impossible, but would seem to be a rather daunting problem.

Given these challenges, I think the simplest approach for us is to provide two versions as we always have, one with audio description and one without. The version that users receive is controlled by a user preference.

However, this unfortunately doesn't sound as simple as recording a simple narration and feeding it to the player as an MP3. So after all this talk, I'm still puzzled. What is it going to take to get everyone who creates a video to add captions and audio description to that video?

Struggling with Understandability

noreply@blogger.com (Terrill Thompson) — Fri, 19 Dec 2008 01:25:00 +0000

Last week the World Wide Web Consortium's (W3C's) Web Content Accessibility Guidelines (WCAG) 2.0 became a "W3C Recommendation", i.e., an official standard. In the current installment of my ongoing series on WCAG 2.0, I'm sharing my experiences with the following success criterion:

3.1.5 Reading Level: When text requires reading ability more advanced than the lower secondary education level after removal of proper names and titles, supplemental content, or a version that does not require reading ability more advanced than the lower secondary education level, is available.

This is a Level AAA requirement, so unless you're trying to attain maximum accessibility it probably won't be of huge concern to you. However, before you dismiss it entirely, I encourage you to give it some thought. This is one of the few WCAG 2.0 success criteria that we at DO-IT had considerable difficulty meeting in our DO-IT Video Search application, and we still haven't quite reached a measurable level of conformance on all pages. However, this success criterion has caused us to think differently as we choose our words in written communication, and I think that's a good thing.

In higher education, I've heard a lot of grumbling about this success criterion from faculty members. Why should they write for a lower secondary level audience, when their audience consists of college undergraduate or graduate students, if not a higher-educated audience of scholarly peers?

The answer is very well explained by the W3C in the WCAG 2.0 supplemental page on Understanding Success Criterion 3.1.5. As the W3C explains, word length and sentence complexity have an effect on the ability of individuals with reading disabilities such as dyslexia to decode the words on a page. These individuals can sometimes spend an enormous amount of mental energy decoding complex text, even if they are highly educated individuals with specialized knowledge of the subject matter. We authors can relieve some of this burden, and make our content easier for everyone to read, simply by being aware of the words we're choosing, and occasionally opting for smaller words and shorter sentences.

How to measure readability of text is a problem that researchers have been exploring for nearly a century. Some of the earliest work that I'm aware of in this area is that of William Gray and Bernice Leary, who wrote the book "What makes a Book Readable?" way back in 1935. Their pioneering work included experiments in which they manipulated dozens of linguistic variables and attempted to identify which variables had the greatest impact on human subjects' ability to read the text. Other researchers have built upon the knowledge gained in these early tests.

Perhaps the most influential of these researchers was Rudolf Flesch, who developed readability tests based on numbers of words and syllables, and conducted research experiments to validate these results against results of tests with human readers. The Flesch Reading Ease test and Flesch-Kincaid Readability Test both measure readability based on slightly different formulas using the number of syllables, words, and sentences.

Gez Lemon of Juicy Studio has incorporated both Flesch tests, plus one other (The Guning-Fog Index) into an on-line Readability Test. It couldn't be much simpler: Just plug in the URL of a web page and find out how readable that page is.

In testing the DO-IT Video Search site, we were pleased to find that the transcripts of all our videos actually met the success criterion. This wasn't altogether surprising, as we recognize that the audience for our videos includes lower secondary level students, and we consciously write our video scripts with that in mind.

We failed though on two pages. The first was the FAQ, which was written with an audience much like myself in mind: someone who is somewhat technical, and is comfortable with larger-than-average words. You, dear blog reader, are also assumed to be in this category.

The other page that failed the readability tests was our home page. This page posed unique challenges, because the home page consists mostly of titles and brief descriptions of each of our videos. Our titles include words like "disabilities" and "accessibility" and phrases like "postsecondary education". DO-IT itself stands for "Disabilities, Opportunities, Internetworking, and Technology". Obviously we can't easily change any of this. We actually can claim at least some of the credit for the phrase "after removal of proper names and titles", which was added to the Success Criterion after we explained our dilemma to the WCAG Working Group.

Although we couldn't make our name or titles more understandable, we did find some room for improvement in the video descriptions. Here are some examples:

We changed "Testimonials from employees with disabilities..." to "People with disabilities talk about..."
We changed "a fully inclusive postsecondary learning environment" to "a higher education learning environment that includes all students"
We changed the word "manipulated" to "changed"
We changed the word "participants" to "students"
We changed the word "subsequently" to "later"

As a result of our effort to conform to WCAG 2.0, I find that in general I'm more aware, and I'm choosing simpler words. I've even done so a few times while writing this blog post, which, according to our test results, is very easy to read (hopefully you agree):

Reading Level Results for This Blog
Summary	Value
Total sentences	232
Total words	1399
Average words per Sentence	6.03
Words with 1 Syllable	864
Words with 2 Syllables	307
Words with 3 Syllables	130
Words with 4 or more Syllables	98
Percentage of word with three or more syllables	16.30%
Average Syllables per Word	1.62
Gunning Fog Index	8.93
Flesch Reading Ease	64.05
Flesch-Kincaid Grade	5.82

The Guning Fog and Flesch-Kincaid Indexes are both expressed in number of years of schooling required for understanding the content. So, this blog is readable either by an eighth grader or a fifth grader, depending on which scale you trust most. The third measure, the Flesch Reading Ease index, is a 100-point scale, where a higher number reflects better readability (the goal for WCAG 2.0 readability is a score of roughly 60-70).

For comparison, here are the same results for the WCAG 2.0 document, which is considerably less readable than this blog, and not quite conformant to itself:

Reading Level Results for WCAG 2.0
Summary	Value
Total sentences	1808
Total words	15048
Average words per Sentence	8.32
Words with 1 Syllable	8609
Words with 2 Syllables	3290
Words with 3 Syllables	1800
Words with 4 or more Syllables	1349
Percentage of word with three or more syllables	20.93%
Average Syllables per Word	1.73
Gunning Fog Index	11.70
Flesch Reading Ease	52.30
Flesch-Kincaid Grade	8.03

Will SC 3.1.5 result in web pages that are easier to understand? Or will web authors load their source code with simple text and hide it off screen using CSS, just to pass the readability tests?

Hopefully no one will do the latter. And if they do, hopefully they won't credit me with this brilliant idea.

My hope in spreading the word about this topic is that authors will simply pay attention to the words they use. Check the thesaurus for smaller words, not bigger ones, and if you can say it more simply, do it.

DO-IT Video Search Meets WCAG 2.0, Part 2

noreply@blogger.com (Terrill Thompson) — Fri, 14 Nov 2008 13:51:00 +0000

I began writing this blog post yesterday morning as the sun rose in Boulder, Colorado, and Boulder's landmark Flat Irons slowly faded dramatically into view. Twenty-four hours later, the Flat Irons are obscured by falling snow, and Boulder is waking beneath a thin sheet of white. I'm here for Accessing Higher Ground, the annual gathering of higher education access technology professionals. Yesterday I gave a presentation titled DO-IT Video Search: A Case Study in Accessible Multimedia. The link points to an accessible PDF version of my Powerpoint slides.

In my presentation, I discussed and demonstrated DO-IT Video Search, and concluded with discussion of our efforts to comply with the World Wide Web Consoritum (W3C) Web Content Accessibility Guidelines (WCAG) 2.0. This blog post is the second in a series related to these efforts.

Similar to version 1.0, WCAG 2.0 has various levels of conformance, designated as AAA (maximum accessibility), AA (not bad), and A (critical accessibility needs are met). If a web site fails to comply with Level A success criteria, the site is sure to exclude certain groups of people.

I've been an advocate for web accessibility since the early 1990's, so many of the WCAG 2.0 success criteria are no brainers. All of our images have meaningful alternate text for people who can't see them. All of our videos are captioned for people who can't hear them (In fact, without captions are video search applications wouldn't even exist since captions are what make the full text of our videos searchable). All of our pages have good HTML structure, using appropriate markup to designate headings, subheadings, lists, etc.

However, even after working in the accessibility field for two decades, I still had problems meeting a few of the WCAG 2.0 success criteria. Some of these were minor problems, but some were major problems that ultimately prevented us from attaining Level AAA conformance. The following is a summary of those success criteria that we had to think twice about. The major issues are identified as such, and will be described in more detail in future installments in this series.

Level A Conformance

Captions

1.2.2 Captions (Prerecorded): Captions are provided for all prerecorded audio content in synchronized media, except when the media is a media alternative for text and is clearly labeled as such.

As noted above, captions are a no-brainer. We wouldn't thinking of making video available without them. However, familiarity sometimes leads to complacency, and we discovered (thanks to the WCAG Working Group) that some of our captions were out of sync. How out of sync is too out of sync? This obviously a judgment call, but in our case captions were off by a few seconds in some places, enough to be a problem both for accessibility and searchability. Since we have nearly forty videos, averaging about fifteen minutes each, correcting the problems required that each video be viewed in its entirety, paused at problem points, and timestamps adjusted accordingly. We created a simple caption editor to facilitate this process, and handed the task off to a couple of patient, detail-oriented students who did a fantastic job identiying and fixing all the caption problems. The entire process took less than a week.

Keyboard Accessibility

2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints.

2.1.2 No Keyboard Trap: If keyboard focus can be moved to a component of the page using a keyboard interface, then focus can be moved away from that component using only a keyboard interface, and, if it requires more than unmodified arrow or tab keys or other standard exit methods, the user is advised of the method for moving focus away.

Both of these success criteria are problematic because we're using a Flash media player. There are now several Flash media players available that were designed with accessibility in mind (e.g., controller buttons are labeled and accessible to screen reader users). However, in most browsers the Flash object can't receive focus unless the user first clicks on it with a mouse. As far as I know, the lone exception is Internet Explorer, which supports tabbing seemlessly into and out of Flash objects. However, in other browsers, you have to click to get in, and once you're in, you're trapped unless you click again. Screen readers are able to bypass all this clicking nonsense, but it's a serious problem for sighted users who have physical disabilities, or anyone else who is unable to use a mouse or simply doesn't have one.

One could argue that the success criterion is met because Flash is accessible in IE, but for me that conjures up unpleasant memories from the "Works best in Netscape" days. Our solution was to provide a set of HTML buttons that allows users to control the Flash media player from outside of Flash. The need for this functionality limits are choice of media players, but JW FLV Media Player has worked out wonderfully. It provides all the accessibility features we need (support for captions and audio description, screen reader accessibility (in some versions)), plus it has a powerful Javascript API that allows us to control it externally.

Page Titles

2.4.2 Page Titled: Web pages have titles that describe topic or purpose

This is another no brainer, but should not be overlooked.

HTML Validation

4.1.1 Parsing: In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.

As a standards advocate, I confess to feeling a bit embarassed when the WCAG Working Group pointed out that our site fails to validate. It had validated, but I broke that during an upgrade and neglected to doublecheck. This just goes to show you how important it is to keep the W3C Validator bookmarked and handy, and use it liberally.

Does validation really matter, if the web page seems to work anyway despite having a validation error? My answer to this is unquestionably yes. Standards are the language in which all players in the web community (authors, browsers, assistive technologies, etc.) communicate. The only way to ensure that our message is correctly delivered is to use the language correctly. If we don't, maybe it's true that giant desktop browsers such as Internet Explorer and Firefox will understand us, but as browsers get more diverse (e.g., small footprint browsers on pocket devices) validation is sure to play an increasingly critical role.

Level AA Conformance

Contrast

1.4.3 Contrast (Minimum): The visual presentation of text and images of text has a contrast ratio of at least 5:1 (with some exceptions).

WCAG 1.0 had a similar checkpoint, and I've advocated often for high contrast. However, in WCAG 1.0 the checkpoint called for "sufficient contrast" and it was left to the web designer to make that judgment. With WCAG 2.0, there's a specific ratio to aim for, and there are tools to measure it such as The Paciellos Group's Contrast Analyser.

Now that contrast is measurable, I find that my past judgment as to what's acceptable was a bit liberal. I generally opt for black text on a white background, adding only a dash of color here and there for a richer aesthetic. However, where I did choose to add color on the DO-IT Video Search site (e.g., the HTML buttons that control the media player), the original contrast was insufficient.

When faced with making this change, I found in myself a resistance that I think many web developers experience. I liked my design, and really didn't want to change it. But letting go to such attachments is a good practice. I did let go, and now that some time has passed I actually like the new, higher contrast buttons.

Level AAA Conformance

Transcript

1.2.8 Media Alternative: An alternative for time-based media is provided for all prerecorded synchronized media and for all prerecorded video-only media.

In plain English, this success criterion calls for a video transcript. I have always been a believer in transcripts. They provide a needed accessibility solution for deaf-blind individuals (captions only help deaf users who can see them). They also provide an accessibility solution for people who can't access video due to slow Internet connections, and provide quick access to content for users who don't have 15 minutes to watch the full video.

In fact, I would include transcripts in my "no brainer" category. So why do I include them in this discussion? Our transcripts, like most transcripts, included only the audio content. An important missing component was the copntent of the audio description. People who are reading the transcript are in the same situation as people who can't see the video: If content is presented visually, they don't have access to that information unless the visual content is described.

When the WCAG Working Group brought this to our attention, it sort of through a monkey wrench in our application. In DO-IT Video Search, the transcript is generated automatically from the closed captions. It reads the captions, intelligently adds some formatting code, and writes them to the screen as a transcript. In order to add audio description, we had to modify our production process so that audio description content was added to the caption database, complete with timestamps. Importing captions into the database was simple since captions exist in structured, easily parsed text files. Our audio descriptions don't exist in a similar format: Our vendors generate a script before recording, but it's just written out in a Word file, with no structural markup that would support its being automatically parsed. Perhaps this is something we can discuss with our vendors, but for now adding audio description to the database is a manual process. Again, thankfully we have access to students!

In terms of delivery, our transcripts now include audio description. It's stylized distinctly so it's clearly apparent to visual users that it's different than captioned text. For non-visual users, there's a hidden <span> element (accessible only to screen reader users) that identifies this content as an audio description.

Speaking of audio description...

Audio description

1.2.7 Audio Description (Extended): Where pauses in foreground audio are insufficient to allow audio descriptions to convey the sense of the video, extended audio description is provided for all prerecorded video content in synchronized media.

1.4.7 Low or No Background Audio: For prerecorded audio-only content that (1) contains primarily speech in the foreground, (2) is not an audio CAPTCHA or audio logo, and (3) is not vocalization intended to be primarily musical expression such as singing or rapping, at least one of the following is true: [the specification lists three criteria: No background, background sounds can be turned off, or there's a 20 decibel difference between foreground and background.]

Our videos have been professionally audio described by three different vendors, all leaders in the industry. Therefore, our failure to meet these success criteria suggests that the WCAG 2.0 guidelines are not reflective of standard practices in the industry. I'll be talking much more about this issue in a future installment. Please stay tuned...

Sign Language

1.2.6 Sign Language: Sign language interpretation is provided for all prerecorded audio content in synchronized media.

This is a new requirement in WCAG 2.0, and is not something we had considered previously. We had always felt that closed captions were sufficient for providing access to the deaf and hard of hearing. The reason this success criterion exists is that for many deaf individuals, written language is a second language. Reading English captions is more difficult for these individuals than following along with a sign language interpreter. For some individuals English captions aren't a solution at all.

This is a complex issue with complex solutions, and warrants a blog post of its own. Please stay tuned...

Visual Presentation

1.4.8 Visual presentation: For the visual presentation of blocks of text, a mechanism is available to achieve [an easily readable format, as defined by five stylistic requirements].

This success criterion requires the implementation of specific visual styles designed to make the page easy to read for certain individuals with cognitive, language, and learning disabilities, as well as low vision. One of these items I found to be confusing as written:

line spacing (leading) is at least space-and-a-half within paragraphs, and paragraph spacing is at least 1.5 times larger than the line spacing

My confusion stemmed from my lack of certainty about "line spacing". Since there is no line-spacing property in CSS, I wasn't sure how to intrerpret this requirement. If the font size is 1em, and line spacing is the space between lines, then attaining a line spacing of 1.5em within paragraphs would require a CSS line-height of 2.5em, which I think has the opposite of the intended effect: The page becomes more difficult to read for most people. After some discussion with the WCAG Working Group, I now think I understand that that line-spacing and line-height are synonymous, and this requirement would therefore be met with the following style definition:

p {
font-size: 1em;
line-height: 1.5em;
margin-bottom: 1.5em;
}

Abbreviations

3.1.4 Abbreviations: A mechanism for identifying the expanded form or meaning of abbreviations is available.

On our site, specifically on the FAQ page, I had used abbreviations such VHS and DVD, figuring they're common enough that people are morely likely to recognize and understand VHS than "Video Home System". However, the WCAG Working Group cautioned that I shouldn't make assumptions about users' vocabularies, and I respect that. However, I struggled with the best strategy for delivering this information in a way that would be accessible to folks who need it, but not obtrusive to folks who don't. Consider this HTML:

In some browsers (e.g., Firefox 3, Opera 9.5), this content appears visually with a dotted underline. In others there is no visual distinction, so to be safe I added the following CSS definition:

abbr { border-bottom: thin dotted #000; }

In all browsers the title of the abbreviation appears in a tooltip when users hover with a mouse. However, without additional markup an <abbr> element does not receive focus when a keyboard user is tabbing through the document, so this markup is currently inaccessible to non-mousers. Also, screen readers may or may not have access. In JAWS 9, there are configuration options to expand abbreviations and acronyms, but these are off by default. If the user turns them on, then they get the expanded text, but not the original text. Therefore a JAWS user would hear "Video Home System" rather than "VHS", which may arguably be more confusing. My personal workaround is to repeat the abbreviation in the title of the <abbr> tag, like this:

That may not be pure semantic markup, but it seems to make abbreviations more accessible to screen reader users.

Reading Level

3.1.5 : Reading Level: When text requires reading ability more advanced than the lower secondary education level after removal of proper names and titles, supplemental content, or a version that does not require reading ability more advanced than the lower secondary education level, is available.

Measuring reading level is challenging, and worthy of a thorough discussion in a future post. Please stay tuned...

DO-IT Video Search Meets WCAG 2.0, Part 1

noreply@blogger.com (Terrill Thompson) — Sat, 08 Nov 2008 18:03:00 +0000

Last week, while the world was distracted by the U.S. election, the World Wide Web Consortium (W3C) published the WCAG 2.0 Implementation Report. This means they are one step closer to the Web Content Accessibility Guidelines (WCAG) 2.0 becoming an official "W3C recommendation", that is, a web standard.

Among the web sites listed by the W3C as successful implementations is our own DO-IT Video Search, an application that allows people to search the full text of the DO-IT video library using closed captions.

As W3C notes in the implementation details for DO-IT Video Search, we tried to attain Level AAA conformance (the highest level of accessibility), and failed, settling instead for Level AA conformance.

This was no small effort, and I think there's much to be learned from our failures as well as our successes. This blog post is the first in a series that will explore our efforts to conform. Stay tuned over the coming weeks for an overview of our WCAG 2.0 conformance efforts, plus in-depth play-by-play of our experience with WCAG 2.0 success criteria related to reading level, audio description, and sign language.

I'll also be talking about all of this at 3:30pm on Thursday (11/13/08) at the Accessing Higher Ground conference in Boulder. I hope to see many of you there!

Sittin' Down With Spain

noreply@blogger.com (Terrill Thompson) — Mon, 20 Oct 2008 04:03:00 +0000

OK, so I couldn't resist the urge to record a political tune. My main motivation was a Spanish-influenced chord progression that had been looping in my head for a while. Then, a couple of weeks ago John McCain, exemplifying his Bushian strategy of refusing to talk with foreign leaders who don't agree with him, refused to meet with Prime Minister Zapatero of Spain. This issue came up in both the presidential and vice presidential debates, and it, shall we say, struck a chord.

How do we work out our disagreements unless we talk? This is something my eight and ten year old kids are starting to understand. In doing so they've learned that talking through problems requires listening and trying to develop an understanding of the other person's perspective. Why is it so far-fetched for world leaders to apply this basic playground principle to their own interactions?

I could go on and on about this issue, but instead I think I'll leave politics for another day, and just share my music. I call my new tune "Sittin' Down With Spain". Check it out at myspace.com/flowtheory.

And those of you who are U.S. citizens, please vote!

Accessibility of Javascript Frameworks

noreply@blogger.com (Terrill Thompson) — Tue, 07 Oct 2008 11:04:00 +0000

On Day 1 of the HighEdWeb conference, one strong impression I got was that everyone is either using or considering using one or more Javascript frameworks to speed up their web development. Javascript frameworks are libraries of pre-written widgets or controls that developers can essentially plug into their websites without having to develop them from scratch.

There are two questions that came up repeatedly at the conference:

How does a newbie to Javascript frameworks decide which one to use?
Which Javascript framework is most accessible?

There are many excellent blogs that discuss the choice between frameworks (just Google "Choosing a Javascript framework"). Favorite frameworks, judging by the blogger buzz and by discussions at HighEdWeb, seem to be jQuery, Yahoo! User Interface (YUI), MooTools, Prototype/Scriptaculous, and Dojo Toolkit. Many of the blogs raise excellent questions that folks should ask in considering which framework is right for them. However, few blogs recommend asking whether the framework produces accessible output. To me, this is a critical consideration, and I've been pleased to hear it asked so frequently here at HighEdWeb. If websites of the future are going to all be built from the same re-usable code, then the accessibility of that code will have a huge global impact on web accessibility.

So, which Javascript framework is most accessible?

The Wikipedia entry on Comparison of Javascript Frameworks presents a large data table comparing over a dozen frameworks on over a dozen features, including "Accessibility /graceful degradation". In the current version of this Wikipedia page, frameworks are rated with either "Yes" or "No" on this variable, which would seem to be an oversimplification. I've tried below to provide more extensive information about the current state of accessibility for the more popular frameworks.

A key to accessibility of interactive web controls is their support for the W3C's draft Accessible Rich Internet Applications (ARIA) specification. ARIA addresses the accessibility of dynamic web controls by defining a method by which developers can specify roles and states of custom HTML widgets. Supporting browsers pass this information on to supporting assistive technologies.

There doesn't seem to be much talk about accessibility within the MooTools or Prototype/Scriptaculous communities, which I suspect would indicate inaccessible code, but I'd love to be corrected. Another framework, Ext JS, has published a Ext JS Roadmap which includes "ARIA/Section 508 accessibility improvements" among the features slated for inclusion in the Ext JS 3.0 release, scheduled for Winter 2008 or Early 2009.

The following is a summary of frameworks that from my perspective seem to be taking accessibility most seriously:

Dojo Toolkit

Dojo was the first framework to have substantial accessibility support. The core widget set of Dojo has included accessibility support since the release of Dojo 1.0 in 2007, including full keyboard support, ARIA support, and support for high contrast mode. According to the Dojo A11Y Statement, they are still "the only fully accessible open source toolkit for Web 2.0 development." That may be true, but I think one or two of the others may be catching up.

Dojo also includes extensive accessibility documentation in its on-line manual, The Book of Dojo. Becky Gibson of IBM's Emerging Technologies group is Dojo's accessibility lead, and she presented an excellent and unbiased paper at the 2007 W4A conference in Banff titled Enabling an Accessible Web 2.0 (in PDF). I spent a few days hiking solo among grizzlies and elk prior to that conference, but that's another story...

jQuery

The jQuery Accessibility community is actively working to build accessibility support into jQuery. One significant development was Chris Hoffman's jARIA plug-in, which extended the jQuery object with a set of ARIA methods. In an announcement posted to the community on September 22, David Botter says that ARIA functions have now been integrated into jQuery UI's core. This would seem to be a very promising new development.

Yahoo! User Interface

Yahoo! has been adding accessibility to its widgets since 2007 if not earlier, as documented in their blog post Using WAI-ARIA Roles and States with the YUI Menu Control. However, their support for accessibility still seems to be isolated, although slowly expanding. In a blog post on October 2 titled ARIA Plug-Ins for YUI Widgets, they announced that "a handful of widgets" now include ARIA support.

Google Web Toolkit (GWT)

Google Web Toolkit is a Java toolkit, rather than a Javascript toolkit, but nevertheless deserves mention here. On September 5, Google announced built-in accessibility support in GWT 1.5, the latest release. Support is provided by baking ARIA roles and states into core widgets, and by providing an Accessibility class that allows accessibility to be added to developers' custom widgets.

For my own development efforts, I've getting my feet wet with jQuery, and as time permits I may have a look at Dojo and YUI as well. If others have firsthand knowledge of accessibility of a particular framework, please share your stories and observations!

The Eye vs. The Eye

noreply@blogger.com (Terrill Thompson) — Sat, 27 Sep 2008 17:54:00 +0000

Last week I watched "The Eye", the 2002 Chinese thriller directed by the Pang Brothers and starring Angelica Lee (aka Lee Sin-Jee) as Mun, a young blind woman who receives a corneal transplant, and discovers that she can see ghosts. I was mesmerized by this film. The suspense was great, the soundtrack was interesting and superbly mixed for maximum dramatic effect, and Lee's acting was convincing and superb (and resulted in her winning several best actress awards in Asia). I was so impressed with this movie that I immediately added the Hollywood remake (2007, starring Jessica Alba) to my Netflix queue.

Having now seen both versions, I feel compelled to compare them. I don't claim to be a cinematic critic, so I'll compare them from the standpoint of an access technologist. I have a long interest in how disability is portrayed in the media, and The Eye is especially interesting since the two versions of the film come from different cultures. People with disabilities, like people from other minority groups, have a long history of being stereotyped and ridiculed in cinema. However, I think both versions of The Eye portray the lead character as a person with dignity, strength, intelligence, and a solid ability to live independently. Both films open with the character striding confidently down a crowded urban sidewalk. In the Chinese version she's using a red umbrella, while in the U.S. version she's using a white cane (she does use a white cane later in the Chinese version, so I'm not entirely clear on the symbolic function of the umbrella, but that's why I'm not a film critic). In both versions the character encounters an accessible crosswalk (in China it's clicking, in the U.S. it's chirping). In the U.S. version she saves the life of an iPod-wearing skateboarder who almost enters the crosswalk into the path of a speeding bus. OK, so maybe that's over the top, but it does show how incredibly capable this blind woman is!

When the character gets home after her pedestrian commute, we see in both versions that her home is well-organized, and that she lives alone and is able to live a fully independent life. In the Chinese version the character's portrayal prior to the corneal transplant is very brief. What I just described is pretty much the extent of it. She changes into her PJ's, climbs into bed, then after the opening credits she wakes up in the hospital following her surgery. In the U.S. version, the pre-surgery character development is a bit longer. She's an accomplished violinist, and spends her days practicing with the orchestra. In the Chinese version, she plays the violin but her skills are comparatively rough, at least in the beginning, and she plays in an all-blind chamber orchestra. Interestingly, she is told after her corneal transplant (despite still having extremely blurry vision) that she will no longer be allowed to perform with the group, since she is no longer disabled. I found this to be interestingly reminiscent of the debate in the U.S. over whether a person with a disability continues to have a disability if their disability is offset by mitigating measures such as medicine (or a corneal transplant). This debate was fueled in the U.S. by multiple Supreme Court decisions that narrowed the definition of disability covered by the Americans with Disabilities Act (ADA). These decisions were finally overturned this past Thursday when President Bush signed the ADA Amendments Act. So, it's interesting that this issue should come up in the Chinese version of the film.

Following the lead character's corneal transplant, the story becomes the thriller it was intended to be, as the character begins to see things that others can't, but since eyesight is new to her it's difficult for her to distinguish the ordinary from the supernatural. There's a minor subtext throughout the film of the character wishing she had not had the surgery, and appreciating how good she had it when she was blind. This is particularly drawn out in the U.S. version, including one dramatic scene in which she puzzles over the complexities of a printed musical score, then ultimately tosses it aside and returns to her Braille score.

There's also a considerable amount of assistive technology in the U.S. version, not true of the Chinese version. The U.S. character has a talking alarm clock, and uses a computer equipped with some sort of highlight-and-read application, like Kurzweil 3000. I didn't recognize the product, and I found it curious that a life-long blind person would be using a product with visual features rather than a screen reader developed specifically for people with no sight. Similarly, I found it curious that she had her speech output set to a very slow speed, even slower than the default setting on most products. Perhaps this is a new product that she acquired post-surgery, and she hasn't yet figured out how to use it effectively. I should check the deleted scenes for more clues.

She also has an Enabling Technologies Juliet Braille embosser, featured prominently in a climactic scene in which she discovers "Cellular Memory" on a Medical Dictionary website. This is actually a curious scene: She's reading the page with highlight and speech, yet typing frantically at the same time, while her Juliet prints pages upon pages of Braille content which accumulate in a large pile on the floor. I guess all this I/O activity was designed to maximize the tension of the scene, and it works for me, but only because I feel like all her technology is freaking out at once, and I can relate to that. As a footnote to this paragraph, the Medical Dictionary website seems visibly to be quite accessible. It mostly contains text, and seems to have good heading structure. I watched this scene closely for signs of alternate text on images, but the director apparently decided to leave this detail for audiences to ponder.

I should also mention accessibility of the medium. The U.S. DVD includes TheatreVision audio description, superbly acted by Danny Mora. I actually watched the U.S. version entirely through a second time with audio description because it brought so much more excitement to the production. The Chinese version, at least the release that I received from Netflix, has English subtitles but no audio description. It does, however, feature opening credits in Braille. Not that this would do blind viewers any good, but it's a cool visual effect.

Final impressions: Both The Eye and The Eye are good, entertaining flicks. It's rare these days for a scary movie to approach scariness without resorting to graphic gore, and I appreciate both versions for accomplishing that. I came away with a slight preference overall for the Chinese version - it's darker, tighter, better acted, better directed, and more believable. However, if it's assistive technology you're after, or if you require or prefer a film with audio description, the U.S. version is the one for you. Both films treat blindness with respect and realism, and I think they both provide a positive portrayal of people with blindness in their respective cultures.

Next up in my Netflix queue: The Diving Bell and the Butterfly.

My New Original Name

noreply@blogger.com (Terrill Thompson) — Fri, 12 Sep 2008 11:37:00 +0000

Today the clock strikes 45. It's my birthday, and after 45 years as Terry Thompson (yawn), I'm celebrating this day by changing my name.

Mind you, it's nothing nearly as dramatic as Cat Stevens changing his name to Jusuf Islam, or Robert Zimmerman to Bob Dylan, or Gordon Sumner to Sting, or Paul Hewson to Bono, or Declan McManus to Elvis Costello, or Don Van Vliet to Captain Beefheart, or Arnold Dorsey to Engelbert Humperdinck, or Cordazer Calvin Broadus Jr. to Snoop Dogg, or Sean Combs to Puff Daddy to P. Diddy to Diddy.

In fact, by changing my name I'm not changing my name at all. I'm returning to my original name, the one my parents lovingly gave me: Terrill Thompson.

Why? I could answer this question by framing the name change as an icon representing this monumental transition into a new era in my life (middle age). Or I could answer that I've wanted to do this for a long time, ever since my lifelong buddy Mike (best friend since second grade) invited dozens of his closest friends over for dinner decades ago and proudly proclaimed from the head of the table that he was now Michael, not Mike. Michael embraced his new identity with style and never looked back. I've always admired that.

However, the main reason I'm changing my name is practicality. A Google search for "Terry Thompson" yields 512,000 results (4.6 million if I drop the "p"). While living twelve years in Lawrence, Kansas, the other Terry Thompson and I often received each others' mail, phone calls, banked at the same bank, went to the same doctor. It was quite confusing. Now in Bellingham, Washington, I'm enduring the exact same thing with Terry Thompson, who actually sat next to me on a recent flight from Seattle (we're both IT professionals, as well as Alaska Air MVP's). Imagine this, which actually happened:

"Your name, sir?"
"Terry Thompson"
"You've already checked in, sir."
"No I haven't".
"Yes you have."
"I'm telling you, I haven't".
"I'm telling you, you have."

In contrast, a Google search for "Terrill Thompson" returns only 641 results, and many of them are mine!

I've been gradually transitioning toward this day for a while now, but the transition was officially complete today when I replaced "Terry" with "Terrill" in my Facebook profile, and clicked the "Change Name" button: