Accessible Video and Transcripts

With HTML5 on the horizon, it is becoming far easier to embed video on a web page than it has been. Sure, you can drop some code copied from YouTube, but you have little control over the HTML or the video output. Once you do have your video, you also need to bear in mind that not only are video (and audio) transcripts good practice, they are required by law for many organizations.

HTML5 Video Captions

Bruce Lawson has been kind enough to put together an example and code (Accessible HTML5 Video with JavaScripted captions) for his method to embed synchronized captions, using JavaScript for the synchronization, with a video embedded using the HTML5 video element. The caveat here is that you need to have a browser that supports the open Ogg Theora codec. You can check out the sample video if you have such a capable and sweet browser.

YouTube Automatic Captions

Some of you may remember my post about how YouTube can now automatically caption your videos using speech recognition software. While the results can be interesting, you can at least edit the captions coming out of YouTube. Terrill Thompson describes how he grabbed the .sbv caption file from his video and updated it, then uploaded it back to YouTube for a much more useful result.

Why Transcripts?

Shawn Henry leads the education and outreach effort promoting web accessibility at the W3C Web Accessibility Initiative (WAI). She recently wrote an article titled Transcripts on the Web: Getting people to your podcasts and videos that explains why you would want to do this, some best practices, and even some resources. For example, in addition to supporting users who are deaf or hard of hearing, she points out that search engines can index a transcript where they cannot index a video or audio file. This adds to the overall SEO strategy for any site. Her best practices go beyond what the captions mentioned above provide: she points out that sometimes we need to state how many people in a video raised their hands in response to a question. She is good to not browbeat the reader with a reminder that WCAG 1.0, WCAG 2.0 and Section 508 all require transcripts — at least not until the end of the article.

If you have a few minutes after reading all these other links, consider reading the interview with Shawn Henry, W3C's Shawn Henry on Website Accessibility, from last week over at Freelance Review.

Against Vertical Navigation

There is a well written post over at Smashing Magazine by Louis Lazaris titled The Case Against Vertical Navigation. I have made this argument to my own clients (and other web professionals) many times, often with feedback that implies the client knows how users actually surf. This article wraps up the same points I've made and provides some pretty screen captures. The core points follow...

It Discourages Information Architecture

Using a content management system is the best way to demonstrate how true this is. Sites are no longer made up of a few top pages and perhaps one level of sub-pages. A well-structured press section (with archives and categories) will blow up a left-side navigation structure pretty quickly. It also encourages site authors to keep adding top-level pages until the navigation bar is too long to be useful.

It Wastes Prime Screen Real Estate

So much of the valuable page real estate is taken with vertical navigation that the site will miss out on key promotions or cross-links, partly because authors get more cavalier about the length of words when they are stacked in a column. On longer pages, often the entire column is wasted with dead space below the navigation.

It Doesn't Conform to Real-Life Reading

Vertical navigation results in shorter line-lengths for content, especially if you add images, pull-quotes, cross-sells, blogrolls, and so on to the other side of the page.

Fly-Outs Aren't as Usable as Drop-Downs

Many clients opt for fly-out menus to alleviate the issue with multi-tiered sites, but users don't navigate them as well as fly-outs from a horizontal menu (what the article calls drop-downs). Not only is it physically more of a challenge with a narrower active area, but adding another level gets even more complex for users.

It's Not as Successful, According to Studies

Our own user group studies have shown this, and the article references some research and shows some heat maps that indicate where users look on a page.

The Few Benefits Are Negligible

Having very long names as the primary navigation links can seem like a benefit, but in reality users don't read the entire text, they just parse it for the nouns or action words. The ability to have as many links as you want is also a detriment as users eventually can't keep track of all the options.

Exceptions to the Rule

The author does provide some examples where this rule can be broken. There are some screen shots worth checking out that support the exceptions.

The Latest on HTML5

Many of us have been following the ongoing progress of HTML5 for some time now, alternately curious and confused by the nascent specification. Comics like the one above (from the CSSquirrel site) demonstrate the frustration many web professionals are feeling with the mixed messages they think they see from the W3C and Ian "Hixie" Hickson (HTML5 editor through the WHATWG) through recent updates and announcements.

Kyle Weems opens his blog post (Comic Update: The HTML5 Show (AKA, A Mess)) last week with the statement, "HTML5 is a mess." He argues that Hickson is working to get developers to adopt the WHATWG HTML5 spec over the W3C spec. He also cites examples where he feels Hickson is pushing developers to stop using HTML5 features, and further suggests that Hickson is trying to wrangle the future of all HTML as his own while he hands off an HTML5 version to the W3C while further developing HTML.

Peter Paul Koch (ppk) takes a different approach in his blog post (HTML5 means whatever you want it to mean). Peter references an IRC discussion where Jeremy Keith pointed out that there is no HTML5 spec which he can use for evangelism. Peter argues that HTML5 is vaguely defined almost on purpose, owing to the fact that technologies get pulled into web specs as they are adopted. He suggests that HTML5 is a continuation of Web 2.0, itself a continuation of DHTML. It's similar to the way that Netscape Communications Corp. got table into the HTML3 spec — it introduced them as something its browser supported, and developers jumped on it.

Andy Clarke (Malarkey) looked at it a different way in his blog post (Keep calm and carry on (with HTML5)). He argues, from his own experience, that W3C Working Groups are made of paid members who have an agenda to push their products and needs. He believes that those of us who are actually building web sites should ignore the chaos and just get on with using HTML5, CSS3, or other tools that get the job done. He reminds readers that the specs have changed over the years, as well as the support for those specs. No new HTML5 spec will change the way web developers go about doing their work.

Jeremy Keith (from Adactio) also blogs about this topic (HTML5 business as usual). He points out that the WHATWG is moving ahead on what they now call WHATWG HTML, which contains all of HTML5 as it was forked to the W3C, plus new and upcoming development. Keith then clearly splits the two up for readers to understand that the two specs are divergent — W3C HTML5 is on its way to becoming a candidate recommendation, and WHATWG HTML is the ongoing evolution of HTML beyond version 5. The rest of his post offers some insight into how and why there appears to be so much infighting and why the process is so confusing to those unfamiliar with it.

What Does This Mean for You?

Not a whole lot. In general, if you're a web developer who is just listening, trying HTML5 on projects, or actively evangelizing it, there's really no reason for you to change. The last real shake-up in this world came when XHTML2 was called off and all the XHTML evangelists felt like they were left holding the bag. That's unlikely in this case since there is no other equivalent spec for use in the web browser (not in the same way). All of those dust-ups we've seen are a function of a more public process as the specs are hammered out, something that wasn't much of an issue when the HTML4 spec was being drafted.

What we can expect to see is a new divide in whether people choose to support the W3C HTML5 spec, or the ongoing WHATWG HTML spec. Until browsers start supporting things in HTML5 (which is still not an official spec), then those battle lines may not be drawn for some time. At least not among web developers.

Resources

• W3C HTML5 draft specification (vocabulary and associated APIs for HTML and XHTML): http://dev.w3.org/html5/spec/
• WHATWG HTML5 (including next generation additions still in development) specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/

UPDATE Jan-21-2010: YouTube has rolled out a video player in HTML5 that doesn't use Flash. You need Chrome or Safari (or Chrome Frame for IE) to see how it works, and you may note that some of the features don't behave quite the same, but it's worth trying out. Go to the page to denote your preference for the HTML5 demo player and then surf YouTube as normal.

W3C: Contacting Organizations about Inaccessible Websites

For those of us who make a living working with organizations to help make their web sites accessible to users with disabilities, we've got it easy — the client wants to hear our recommendations. As users, however, all too often we stumble across an accessibility issue and don't know what to do to correct it. Granted, in my case I have a long history of making phone calls until I get somebody on the line, but I can speak the necessary lingo, not everyone else can.

The W3C WAI has just published a document that helps walk users through the steps necessary to contact someone about the issues you find, along with tips and sample emails. They call this document (simply enough) Contacting Organizations about Inaccessible Websites. Those familiar with the W3C should not be surprised that the title bears the [Draft] declaration at the front. The overview from the document (emphasis theirs):

Steps to help you report websites with accessibility problems are described on this page:

1. Identify key contacts
2. Describe the problem
3. Follow-up as needed

Additional tips include:

• Consider what approach will get the results you want
• Keep records of all communications for possible follow-up
• Encourage others to also provide feedback to the organization
• Use the sample emails provided below

Because the document is a public draft, the W3C is accepting feedback up to February 3, 2010. The WAI Interest Group (IG) has a mailing list for public discussion of topics, including this one. There is a little more detail about this process at the blog post announcing this document.

If you've ever been to site and clicked on the words next to a radio button or checkbox and had nothing happen (the button doesn't select), then this document is for you. In this example, the site developer has failed to use the label element. This one is the single biggest issue I consistently encounter (as someone who doesn't use assistive technologies as part of his daily life). So help out by offering feedback on the draft and/or notifying sites of issues.

Article: Lots of Twitter Followers Guarantees... Nothing

I've posted an article over at evolt.org and on my site titled Lots of Twitter Followers Guarantees... Nothing.

I discuss how Anil Dash posted a story called Life on the List where he describes his experience appearing on the Twitter Suggested User List. After watching is follower count shoot skyward, he was left feeling like there was no dialogue between him and these new followers.

The problem here is that employers, sponsors, partners, etc. expect to see high numbers of followers in a social media marketing campaign. Using some examples from Anil's article and framing the context I make my argument that a high follower count isn't necessarily a good thing, and certainly not the only goal.

ALL-CAPS: Harder to Read?

Susan Weinschenk, Ph.D. wanted to write an article about why it's harder to read text set in all-caps than text set as mixed case. The argument for this has centered around how people read words — recognizing a word shape from its letters, whereas an all-caps word has no unique shape. She started to research this idea for her article but could find little to support it. Her article, 100 Things You Should Know About People: #19 — It's a Myth That All Capital Letters Are Inherently Harder to Read, outlines a different method for how letters and word shape work to make it easier for people to read.

In her research she found that people respond to letters they recognize and anticipate, essentially recognizing letter sequences within a word, not the shape of the word. Because of the eye's jumpy nature, thanks to saccades (great article in an old Scientific American issue), your eyes essentially leap ahead a bit and leverage peripheral vision to recognize letters and, as a result, words. A reader can generally pick up 15 letters at a time this way.

From here she argues that text set in all-caps isn't harder to read by its nature, readers just don't have much experience with it. Readers will still take longer to read it, so there is no reason to assume the difference in speed is a myth. They can be trained, however, to bring that speed up.

There is a contrary viewpoint to this, however. A dyslexic writer at the Daily Kos has posted her own plea for writers (blog commentors, etc.) to avoid using all-caps in their comments, posts, articles, etc. This writer claims that she relies on the shape of a word:

However letters mean little to me still I read by a form of pictogram system. Every word has a shape therefore I read the word by its visual form and not its content. [...] [W]hen someone writes in all caps I just cannot see the shape of the intended word [...] I know quite a few dyslexics of varying severity and know that word form is important to many.

In short, while it may be possible to train a reader to recognize all-caps, you certainly won't train your users to do it. Nor do you want to be the application, web site, book, journal, etc. that drives people away in such a misguided attempt. Even if you did manage to train your readers, you would clearly be leaving some selection of dyslexic users out in the cold, perhaps not to return (or worse, to recommend against reading to all their friends).

Architects and engineers who are used to reading all-caps may be excluded from the first part, but I am in no position to form a focus group to test that theory for the scope of this brief piece.

New Tool for Determining Browser Viewport Size

Nine years ago I had become fed up with trying to explain to clients, users, friends, co-workers, and strangers that screen resolution, browser chrome, and browser size combine to create some unique viewport sizes. What this meant was that whether a user had a display at 640x480 or at 1,024x768 was irrelevant if both users had their windows set to the same size. Factor in toolbars, scrollbars, add-ons, and other configuration settings and you had a wide range of viewable space for your web site design that was only loosely related to the actual screen resolution of your end user. I distilled all this down in an article, Real-World Browser Size Stats, Part II (part I described the code I used), written back in 2000 that provided statistics on the viewable area in a browser per screen resolution setting.

Since then many others have started reporting on screen resolutions but few have taken it a step further to report on actual viewable area within the browser. Too many of them, like this chart on the W3Schools site, list the screen resolution trends but neglect to mention that once you pass 1,024x768, users are less likely to surf full screen. Human Factors International even cited my article, but got the conclusion wrong (claiming that as users got more screen real estate they opened more pages).

Today Google has gotten a little closer to getting the point. In a blog post introducing this new tool Google mentions that users were looking at Google Earth, but just not downloading it. After some testing they found the that download button was displaying off screen to the right (outside the viewport) for some users. So they built a tool to help show the breakdown of viewport sizes of users visiting the site as a contour visualization. After seeing some value in this tool for web developers in general, they modified it a bit to make it possible for a user to interact with the page under the contour map. As the mouse moves across a page, a small block of blank space is left around the cursor so that the user can click links or fire hover actions.

Contour map of viewport size statistics.

Head on over to browsersize.googlelabs.com to try out the tool for yourself. When you get there you will see a sample site is already loaded up. The percentiles used in the overlay are pulled from the latest data of visitors to Google.com, so don't think that they numbers necessarily apply to you (my own experience is that for targeted sites they may not). Type the address of your web site (or any site you want to test) into the search box and submit. Give it a little time to load and you are ready to start looking. You can now see what parts of your site are visible (or cut off) at what viewport sizes.

Beware, however, that this tool isn't foolproof. For liquid sites or for sites that float in the middle of the page you may find the numbers don't mesh up as you'd expect. In those cases you can scale your browser window down (width and/or height) to at least get an idea of how it might appear at a specific window size. The numbers on the contour map also don't correspond to known screen resolutions, so you'll need to compare them to other numbers just to be certain you have your data points right. The tool also doesn't account for scrolling, which we all know users do. Instead it shows you how a page might look simply at first load. Because this is a freebie from Google Labs, consider the documentation sparse (which isn't a criticism).

Amazon.com as viewed using the Google Browser Size tool.