Captions in Everyday Use

Yesterday Henny Swan asked a simple question on the Twitters:

I'm curious to know, who uses subtitles on web content (X device) who's not deaf or hard of hearing? For example I did when breastfeeding.

— Henny (@iheni) November 12, 2013

Adam Banks put together a Storify of the responses that show there are plenty of use cases for those not hard of hearing to get value from closed captioning.

In general, any context where either the audio track is loud enough that the viewer doesn't want to disrupt those nearby, or the background noise is too much to hear the audio track clearly, is a case where captions have value for all users. Other cases that popped up include multi-tasking or working with a new language or just tough accents.

In short, closed captions have value for all users.

There is also no reason to panic about providing them, particularly if you use a video service that can do them for you. For example, back in 2010 YouTube committed to enabling auto-captioning for everyone, and Google has documents to help plus tutorials from others, such as this step-by-step or or this video.

Image of the captions in use on President Obama's speech about the Chile earthquake.

Of course, as I was writing this post, Henny posted her own reference to the Twitter conversation: The weird and wonderful reasons why people use subtitles / captions

The Storify of responses I mentioned above is embedded here to spare you all the hassle of clicking the link and to bloat my page with unnecessary script blocks:

Update: November 14, 2013

While I was writing this, Dave Rupert was putting together a very neat experiment, Caption Everything: Using HTML5 to create a real-time closed captioning system.

It's a neat proof-of-concept to show how real-time closed captioning is a possibility with current technology, albeit imprecise and cumbersome. If nothing else, hopefully it can bring more attention to a technique that, as demonstrated above, can benefit all users in everyday situations.

It's such a nifty experiment, I am embedding it here (remember, this isn't mine, this is Dave Rupert's code):

See the Pen Closed Captioning with HTML5 by Dave Rupert (@davatron5000) on CodePen

Read More

Are Patents Killing HTML5 Video?

You may recall from my post in February, WebM, H.264 Debate Still Going, that the H.264 video codec is considered patent-encumbered (which resulted in its dismissal from the HTML5 specification) and Google has argued that its own WebM / VP8 codec is made up of patents it owns, releasing it as royalty-free.

We all had to know it wouldn't be that simple. MPEG-LA, the licensing entity for multimedia codecs such as H.264, put out a call for patents related to VP8, the underlying technology in WebM, back on February 11, leaving it open for a month. Ostensibly MPEG-LA cast its wide net in the hopes that it could find existing patents that it can then use (perhaps by forming a patent pool or preparing for a lawsuit) to lay claim to rights over technology in VP8.

In April, Google started its own call for patent holders and formed the WebM Community Cross-License (CCL) initiative. Its description from its site:

The WebM Community Cross-License (CCL) initiative enables the web community to further support the WebM Project. Google, Matroska and the Xiph.Org Foundation make the various components of WebM openly available on royalty-free terms. By joining the CCL, member organizations likewise agree to license patents they may have that are essential to WebM technologies to other members of the CCL.

With no official announcement, MPEG-LA revealed in an interview (WebM Patent Fight Ahead for Google?) that twelve parties had come forward with patents they felt were covered in VP8. If those claims hold up then MPEG-LA's next step is to create a patent pool, which allows even more patents and patent holders to be added to the mix. It also means Google will be faced with either paying for licensing from that patent pool or defending itself in a lawsuit. Given Google's US $105 million outlay to acquire the VP8 codec (via its acquisition of On2) already, you can bet some number crunching will take place to evaluate the value of either approach.

MPEG-LA most likely doesn't care whether or not VP8 wins over H.264. All MPEG-LA is interested in is getting its licensing fees from both of them. While MPEG-LA doesn't necessarily fit the model of a standard patent troll (it isn't located in Texas), if you read my post from yesterday, A Patent Trolling Primer, you can see some parallels.

These are posts I have written both about patent abuse and the H.264 vs. WebM debate. Instead of a recap of each here, you can get more history in these posts:

• A Patent Trolling Primer, August 1, 2011.


• More Frivolous Patents, July 31, 2011.


• Frivolous Patents on the Web, October 15, 2010.


• WebM, H.264 Debate Still Going, February 21, 2011.


• H.264 Getting Dropped from Chrome, January 13, 2011.

Back in January, Moving Picture Experts Group (MPEG, a working group of ISO/IEC and not related to MPEG-LA) issued a statement that it plans to move forward with a royalty-free video encoding standard. Sadly, I don't have any news on its progress. If you have any, please comment below and let me know.

Other Media Types

As proponents of Ogg Vorbis will tell you on the We Want Ogg site, while they claim that it is a royalty-free and unpatented audio format, they cannot seem to get either Apple or Microsoft to support it in their browsers — even though the code to embed it natively in the browser is available (a better solution than a plug-in). In this case, owning patents related to audio technologies as a browser maker is motivation to not support an open format.

Google's WebP image format, which uses some of the still-image compression tricks from VP8, isn't being supported in Mozilla (Mozilla rejects WebP image format, Google adds it to Picasa). While patent issues around VP8 may certainly creep into WebP, in this case the argument to refuse support for the image format comes down to its lack of clear benefits to other image formats. If VP8 compression formats become patent-encumbered then you can bet this new format will die on the vine.

Related

• MPEG LA: 12 companies own patents essential to Google's VP8 codec


• Royalty-free MPEG video codec ups the ante for Google's WebM/VP8


• Google builds WebM patent pool of its own to fight back against MPEG-LA

Update: March 7, 2013

Today on Google's WebM blog:

Today Google Inc. and MPEG LA, LLC announced agreements that will result in MPEG LA ending its efforts to form a VP8 patent pool.

There is no indication of how much money changed hands.

Read More

Don't Let HTML5 Become the New DHTML

This photo represents some of the technologies (pint glasses) that HTML5 (t-shirt) is thought to encompass (drink). The horror of that concept is represented by the hands (defensive wounds coming).

I had the pleasure of sharing some pints with Bruce Lawson and Chris Mills last week in London. While discussing what bands are emo versus punk rock and during an exchange of favorite phrases to refer to the chronically daft, we touched on HTML5 and its perceptions a bit.

This thought process was rekindled just this week when I got in a discussion with a not-very-technical manager of web projects who insisted on mobile support and decidedly CSS3-based styling by implementing HTML5. The key here is the insistence on using HTML5. For a little context, we use HTML 4.01 Transitional for our projects. It's a valid and complete specification. It allows us to use things like WOFF, CSS3, AJAX, support mobile devices and so on.

I understand that many have co-opted "HTML5" as a brand for a suite of new technologies (most of them even from the W3C or WHATWG). I do not accept that, however, because it confuses the point when it comes time to make choices about technologies. This is a battle I have already fought repeatedly back when DHTML (and IE4!) became the rage and I had clients asking what technologies I would use to build their pages — insisting in advance that it be DHTML. I could explain that DHTML was just a terrible term coined to mean HTML4, CSS and JavaScript, but clients didn't care. It didn't matter to them. Good for them.

For developers and the people that manage them, including those who write on these topics, I have a different expectation than I have from clients. Allowing HTML5 to mean CSS3, geolocation, H.264, or any other technology just makes it harder on us who work in this space. A technology for a project should be chosen based on the goals at hand, not because a client insists on it because of a misunderstanding of a brand or because the press release will sound great when citing how cutting edge everyone is. Most importantly, a technology should not be chosen because of confusion over terminology — least of all when that term actually refers to one particular specification.

Please, fellow developer/writer/manager, make an effort to understand the technologies you reference so you do not confuse other developers/writers/managers, set incorrect expectations with clients, or generally demonstrate that you do not get it (especially if you want to work for me).

I have written on this extensively (with many links in each article that are to further details not written by me):

• W3C Clarifies HTML5 Logo Is for HTML Only


• HTML5 Finally Gets... a Logo?


• Google, Arcade Fire Confused on HTML5


• Google Doodle: Bouncy Balls Aren't HTML5


• HTML5 and CSS3 Confusion

If you are a writer (whether a journalist, blogger or analyst) then please take a few moments to read this useful and informational post: HTML5: notes for analysts and journalists (also not written by me). There will be a quiz. I don't know when, but there will be a quiz.

Now, to reveal how Bruce and Chris really felt about the HTML5 confusion:

Here are posts from both Bruce and Chris discussing this confusion, within the context of the new HTML5 logo muddying the point earlier this year:

• On the HTML5 logo, by Bruce Lawson on January 18, 2011.


• HTML5 logo: be proud, but don’t muddy the waters!, by Chris Mills on January 18, 2011.

Read More

WebM, H.264 Debate Still Going

On February 2, Microsoft released a plug-in for Chrome on Windows 7 to allow users to play H.264 video directly in Chrome. In addition, Microsoft has said that it will support WebM (VP8) when a user has the codec installed. And so began the fragmentation of the HTML video model, back to relying on plug-ins to support what was otherwise intended to be supported natively within browsers.

Microsoft went on to ask three broad questions in a separate post (HTML5 and Web Video: Questions for the Industry from the Community), taking Google to task for what Microsoft considers inconsistent application of its own patent concerns and openness (emphasis Microsoft's):

1. Who bears the liability and risk for consumers, businesses, and developers until the legal system resolves the intellectual property issues;


2. When and how does Google make room for the Open Web Standards community to engage genuinely;


3. What is the plan for restoring consistency across devices, Web services, and the PC.

The same day Microsoft was announcing its plug-in approach to addressing the WebM and H.264 battle, the post On WebM again: freedom, quality, patents came out addressing what it felt were the five most common issues raised with WebM (which I have paraphrased):

1. Quality: the argument here is that it's a function of the encoder and the WebM can match H.264;


2. Patent Risk: comparing the 164 unexpired U.S. patents used in a single encoder, he finds that 126 of them are there for the encoder's H.264 support, the remaining (used by WebM) are in a library released by Google.


3. Not open enough: there is little argument here, given that it's currently in Google's hands to manage and develop.


4. H.264 is not so encumbered: but only for non-commercial use for freely-distributed web video.


5. Google provides no protection from infringing patents: nor does MPEG-LA.

Changing the Nature of the Battle

On February 11, the post MPEG LA puts Google's WebM video format VP8 under patent scrutiny outlines how MPEG-LA, the licensing entity for multimedia codecs such as H.264, has put out a call for patents related to VP8, the underlying technology in WebM. That deadline for submissions is March 18, or less than a month away as of this writing. From there, MPEG-LA will create a patent pool of contributing patent holders for any items that are deemed essential to the codec. This patent pool can then be used to negotiate licensing. In short, VP8/WebM could soon be more patent encumbered than it has been. This puts Google on the defensive as it will have to show that none of the patents in use are valid and/or infringed.

The same author of that last post posted on the 14th at The Guardian, Royalty-free MPEG video codec ups the ante for Google's WebM/VP8. In case that title isn't clear enough, a new royalty-free video standard may be in the pipes. MPEG, a standards body separate from MPEG-LA (the licensing body) has called for proposals toward a royalty-free MPEG video coding standard. One of the goals is to make this new standard comparable to the baseline used in H.264.

If this pans out, it puts another barrier in front of the WebM offering from Google, namely that for WebM to be adopted it will have to best any new royalty-free MPEG codec. The three items that can bring WebM (VP8) down:

1. If the MPEG-LA call for for patents and resulting patent pool for VP8 nets some patents, MPEG-LA will now form a patent pool to push for licensing agreements, which Google will have to fight at each step.


2. If MPEG can genuinely develop a royalty-free video coding standard, it can beat WebM either from the patent perspective or by forcing WebM to be technically superior.


3. Assuming WebM can get past the first two items, it's still back where it started — in a battle for adoption and endorsement against the already entrenched H.264 standard.

Real-World Needs

Considering Google is the company that delivers so much of the video viewed on the web via YouTube, it makes sense that Google presumes it can take the lead on video codec standards. Netflix, however, has its entire business model built around video, which is now moving inexorably to the web. Netflix commented back in December (HTML5 and Video Streaming) that it needs some things sorted out before it can even rely on HTML5 and video to deliver its content (the first 6 of which it has resolved through its own proprietary technology):

1. The acceptable A/V container formats (e.g. Fragmented MP4, WebM, etc.);


2. The acceptable audio and video codecs (e.g. H.264, VP8, AAC, etc.);


3. The streaming protocol (e.g. HTTP, RTP, etc.);


4. A way for the streaming protocol to adapt to available bandwidth;


5. A way of conveying information about available streams and other parameters to the streaming player module;


6. A way of supporting protected content (e.g. with DRM systems);


7. A way of exposing all this functionality into HTML5.

It's clear that the web video debate extends far beyond the academics of HTML5. As long as issues related to patents and licensing are unresolved, or perceived as unresolved, we will see more proprietary solutions gain more ground, further balkanizing the future of video on the web.

If you think this doesn't affect the end user, all that time and effort put into creating proprietary solutions ultimately costs you as the consumer in the form of increased fees for your content. Granted, it will be some time for browsers to catch up with the selected codec, and yet more time for users to catch up with the supporting browsers, but the more this debate continues, the longer before we can even start that long road of user adoption.

Possibly the best outcome we can hope for is that this battle results in a royalty-free MPEG standard, nullifying many of the arguments against both H.264 and WebM.

Related

• H.264 Getting Dropped from Chrome, January 11, 2011.


• Simple HTML5 video player with Flash fallback and custom controls, February 17, 2011.

Read More

W3C and WHATWG Provide HTML5 Updates

W3C

The W3C is pretty good about posting news when new HTML/CSS-related documents undergo updates, status changes, or generally move forward. On Friday the W3C HTML Working Group announced the publication of eight new documents. The brief release provides an even briefer overview of each, or you can see the same list, with the ability to file a bug, at the HTML Working Group home page. The eight documents (all dated January 13, 2011):

1. Working Draft of the HTML5 specification.


2. An updated draft of the helpful HTML5 differences from HTML4.


3. The accompanying non-normative HTML: The Markup Language Reference, which is worth reading through if only to look at the items marked changed.


4. HTML+RDFa 1.1, which outlines support for RDFa in both HTML4 and HTML5.


5. HTML Microdata, discussing support for machine-readable data in HTML, ideally in an easty-to-write manner.


6. HTML Canvas 2D Context, which, I think obviously, defines the API for use with the canvas element.


7. HTML5: Techniques for providing useful text alternatives, a handy document for how to use the alt attribute and other related features (except longdesc).


8. Polyglot Markup: HTML-Compatible XHTML Documents, intended to offer developers guidelines for creating HTML documents that validate as both HTML and XML. It's worth a read just to understand the premise.

For those of you more interested in the progress of accessibility in HTML, you can always drop in to see the weekly W3C Accessibility Task Force (a11ytf) bugs which are just hanging out, waiting to be closed, verified, or sent along to the HTML Tracker. Laura Carlson (of the [webdev] Web Design Update newsletter) sends out a weekly email update with a link to the report, Pre-Last Call "A11ytf" Keyword Bugs Awaiting Task Force Action (these links are both from January 15, 2011).

WHATWG

WHATWG is trying something new — a summary. As the author writes, If this works out you might see another one. There is a chance, then, that you might not see another. At least the document posted on January 16 gives us some updates for now. Read it at Base64, model trains, Web Workers & the DOM, captions, …

Unlike the W3C status update, this one is more casual. It links to emails flying around between the members, allowing you as the user to dive right into a thread and follow it along. It is not scrubbed or converted to non-technical language, so it provides a nice behind the scenes look. For example, there is a link to an email, [whatwg] Google Feedback on the HTML5 media a11y specifications, that provides feedback from Google on the HTML5 media accessibility specifications. As the folks who run YouTube, Google's feedback is important to the success of video on the web, and so Google's rep discusses things like the track element and the caption text file format. Don't expect to see any references to codecs (like the Chrome/H.264 dust-up).

Bonus

Since reading this may have gotten you all excited over the specs and all things related to it, take a few minutes to read this post about a "Shadow Dom:" What the Heck is Shadow DOM? If you play at all with JavaScript (libraries or otherwise), you may be interested to read up on examples such as the new slider input element and how you can access the element within the input — but not via standard HTML/CSS selectors, only via script. After all, if you are implementing it, you will need script to make it do something, so leaving that to the client-side script makes sense as a developer.

There, now you have enough to keep you busy on what might otherwise be a slow Monday at work.

Read More

H.264 Getting Dropped from Chrome

If you pay any attention to the plodding chaos that is the development of HTML5, then you've probably seen the discussions around the video element and how best to encode videos. Over a year and half ago Ian Hickson gutted the video and audio portions of the HTML5 specification to remove all references to codecs, disconnecting the two competing standards, H.264 and Ogg Theora, from the next HTML standard. He did this in an email announcement to the WHATWG list, explaining the issues with licensing and browser support for both options.

At the time Safari refused to implement support for Ogg Theora, Opera and Mozilla refused to support H.264, Internet Explorer was silent, and only Google Chrome implemented both (though Google said it could not provide the H.264 codec license to Chromium third-party distributors).

A year and half later and Google has dropped support for H.264 from Chrome as of two days ago. While Google has hung its argument on the hook of license restrictions, it's probable that Google is really just pushing its own WebM format.

The licensing argument is simple — the compression parts of H.264 are patented by MPEG-LA. While MPEG-LA has opened up the H.264 license for the web (after originally saying it wouldn't collect royalties until 2016), it's conceivable that move was intended to get the web hooked on it. And then it's fair to assume the patent trolling might begin (history indicates the odds are good).

This announcement and the logic behind it has started off a mini-firestorm among developers on the leading edge of HTML5.

Ars Technica wrote up a pretty scathing review of Google's move in the article Google's dropping H.264 from Chrome a step backward for openness, suggesting Google's real issue is about control over its own WebM format. The article goes into more detail about Google acquisition of the company responsible for developing what is now WebM and compares and contrasts the licenses of these and other standards.

Haavard Moen, who works for Opera, takes some time to disassemble the argument made by Ars Technica in his post Is the removal of H.264 from Chrome a step backward for openness? He breaks it up into 11 points, corrects or contextualizes them, and then suggests that the bulk of the points aren't even relevant to the discussion at hand.

The chart below (and its comments) were unabashedly stolen and marked up from a graphic by Bruce Lawson (of Opera Software fame). He uses it to outline which browsers support which codec. I have added a column to list Ogg Theora.

Browser	Ogg Theora	Native webM Support	H.264 Support	Member of MPEG-LA H.264 Licensing Pool
Opera	Yes	Yes	No	No
Firefox	Yes	Yes	No	No
Chrome	Yes	Yes	No	No
Internet Explorer 9	No	No	Yes	Yes
Safari	No	No	Yes	Yes

The two browsers that only support h264 video are Internet Explorer 9 and Apple Safari, the vendors of which have a financial stake in the codec:
www.mpegla.com/main/programs/AVC/Pages/Licensors.aspx

The column in the chart asking about the MPEG-LA licensing pool is intended to show that the only browsers still supporting H.264 are those with a financial stake. Bruce updated his post with a link from a site visitor that claims that Microsoft gets far less from its financial commitment to H.264 than it pays in.

An argument that keeps popping up is that Google should drop support for Flash, given that it is not an open standard. I have dismissed this immediately on the argument that Flash has been here for a very long time, and it's not practical to drop support for a technology that is already driving millions of sites, at least not without the myopic world view that Apple lugs around.

That argument, however, made it into the post from John Gruber's blog, Daring Fireball, titled Simple Questions for Google Regarding Chrome’s Dropping of H.264. Remy Sharp was quick to respond on his own blog with My take on Google dropping H.264.

While Flash is only a part of that debate, it's further insight into the arguments we're hear from both sides. Some of the arguments will lean on a perceived double standard, as we see with the Flash example; some will lean on license debate, as we see with the constant references to MPEG-LA versus WebM and its background; some will lean on the quality of the video, which I intentionally left out of this post; and some will lean on who wants to be the next big monopoly for the burgeoning growth of video on the web.

For the average developer, it might be best to wait until the dust settles. You'll still be making decisions based on browser support in the end anyway.

Related

• Google Chrome drops H.264 support to focus purely on open technologies like WebM


• Google nixes direct H.264 support in Chrome


• The backlash over Google's HTML5 video bet from C|NET.


• Google reveals plan to remove H.264 support from Chrome from ars technica.


• An Open Letter from the President of the United States of Google from MSDN.


• Microsoft mocks Google's Web video decision from C|NET.


• GIF, H.264, and Patents from John Gruber

UPDATE: More Links from around the Innertubes

These links came rolling out this past weekend (January 14-16) and offer more arguments for and against H.264 and Google's decision.

• More about the Chrome HTML Video Codec Change from the Chromium blog.


• Why the Future of Online Video Is in Serious Trouble [OP-ED] from Mashable.


• VIDEO debate, cutting to the chase by John Dowdell from Adobe.


• John Gruber responds with Adobe's John Dowdell on Chrome Dropping H.264 at Daring Fireball (instead of responding right on the blog, where two men can have an open debate).


• Why the Web needs WebM by Anne van Kesteren, who works at Opera.

Update (January 21, 2011)

• A Simple Explanation Of The Huge WebM Versus H.264 Debate

Read More

YouTube Opens Auto-Captioning to All

Image of the captions in use on President Obama's speech about the Chile earthquake.

If you've been reading my blog for a while now then you may have noticed my post back in November titled YouTube Will Automatically Caption Your Video. In that post I talked about YouTube leveraging Google Voice and its speech recognition features to automatically generate video captions. That feature was only available to a subset of all YouTube users, a "small, select group of partners."

On Thursday YouTube announced it will open that feature to all YouTube users (The Future Will Be Captioned: Improving Accessibility on YouTube). In reading the post on the YouTube blog, it looks like they will be working through all the videos on YouTube. Video owners who want to speed up the availability of auto-captions on their videos can click a "request processing" button, hopefully dropping it into a queue. However, since it's a free service, I wouldn't expect them to set a deadline with you.

The blog post lists a few things to keep in mind:

• While we plan to broaden the feature to include more languages in the months to come, currently, auto-captioning is only for videos where English is spoken.
• Just like any speech recognition application, auto-captions require a clearly spoken audio track. Videos with background noise or a muffled voice can't be auto-captioned. President Obama's speech on the recent Chilean Earthquake is a good example of the kind of audio that works for auto-captions.
• Auto-captions aren't perfect and just like any other transcription, the owner of the video needs to check to make sure they're accurate. In other cases, the audio file may not be good enough to generate auto-captions. But please be patient — our speech recognition technology gets better every day.
• Auto-captions should be available to everyone who's interested in using them. We're also working to provide auto-captions for all past user uploads that fit the above mentioned requirements. If you're having trouble enabling them for your video, please visit our Help Center: this article is for uploaders and this article is for viewers.

The obvious benefit here is the ability to satisfy accessibility requirements and open your content to a broader audience. This also can help in your ability to search for videos with appropriate content since the captions live in a separate text file that is pulled into the video, all powered by Google. In addition, with Google's free translation services, it will be far easier to translate videos into multiple languages, reaching an even larger audience.

Read More

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.

Read More

Video Accessible to Keyboard Users

Trenton Moss over at Webcredible has posted an article, Accessible online video for keyboard-only users. The concepts within are very simple, but require developers to take an extra step or two, which may account for why we see so few sites with these features implemented.

One key issue is that developers must not only code client-side script for mouse interaction, but also for keyboard interaction. Since IE behaves differently than other browsers, it must also be written twice (or at least forked). Another factor is the reliance on Flash players, which sometimes won't let you tab into the control from the rest of the page (again, depending on the browser). Regardless of whether the control is in Flash or just HTML with script, then the developer must provide a focus state for each control (so users can tell which is selected) and use a logical tab order.

The author gives the example of making the video slider accessible to keyboard users, perhaps allowing users to directly type in a time stamp so the video will jump to that point. This also benefits users who can rely on a mouse by providing a quick way to jump to a known point in the video. Volume sliders would benefit from this sort of update as well.

Read More

YouTube Will Automatically Caption Your Video

Three years ago YouTube/Google added the ability for video authors to add captions to videos. Over time support for multiple caption tracks was included, the expansion of search to consider text in captions, and even machine translation support for the captions (see my other post about machine translation risks).

Even with hundreds of thousands of captioned videos on YouTube, new videos are posted at the rate of 20 hours of video per minute. For many companies (and not-for-profits and government agencies), YouTube provides the most cost-effective and ubiquitous method to distribute video content to users. So many of these organizations (particularly not-for-profits and government agencies) are required by law (US and elsewhere) to provide captions for video, but don't have the experience or tools to do so. Users who are deaf are excluded from fully understanding this content as a result.

This is where the speech recognition features (ASR) of Google Voice come into play. This technology can parse the audio track of your videos and create captions automatically. Much like machine translation, the quality of these captions may not be the best, but it can at least provide enough information for a user who could not otherwise understand the video at all to glean some meaning and value.

In addition, Google is launching "automatic caption timing," essentially allowing authors to easily make captions using a text file. As the video creator, an author will be able to create a text file with all the words in the video and Google's speech recognition software will figure out where those words are spoken and take care of the timing. This technique can greatly increase the quality of captions on videos with very little effort (or cash outlay for tools) on the part of the video creator.

You can read more at the the YouTube Help Center article. You can also read the blog post announcing this feature at the Google Blog. The video below shows a short demo about the auto-captioning and auto-timing features.

Update (August 25, 2010): Paul Bukhovko of FatCow was kind enough to translate this entry into Belorussian: YouTube аўтаматычна захоплівае сваё відэа

Read More