For Your Reading Pleasure: EasyCaptions

Introducing EasyCaptions: A simple system for adding captions and an interactive transcript to online videos. EasyCaptions uses progressive enhancement to provide the best possible experience for all visitors, regardless of their browser’s JavaScript, HTML5 or Flash support.
Demonstration

Background

I don’t produce much video these days, but as a web surfer I often encounter other people’s videos, and was recently impressed by two video implementations: a TED Talks video page, and an HTML5 video demo produced by Bruce Lawson.

The TED Talks page had a great feature I’d never really seen anywhere else: an interactive transcript of the video that you can read and click. For example, you can click the third sentence of the transcript and the video will jump to that point.

Bruce Lawson’s demo illustrated a dead-simple way to add captions to an HTML5 video using just a wee bit of HTML markup and JavaScript.

Both of these pages shared a unique attribute: they stored complete transcripts of the videos in the markup of the HTML page itself, NOT in an external XML file, as is most commonly seen. What’s the big deal about inline transcripts, you ask? Well, today’s most common captioning options require placing your caption text in an external XML file that loads via ActionScript or JavaScript/AJAX. Both the TED page and Bruce’s demo eschew that approach and place the full transcript in the HTML. This means the transcript is always available to the visitor, regardless of that browser’s support for HTML5, JavaScript or Flash Player.

In both cases, the transcript had been marked up as paragraphs, with extra markup denoting phrases that align with the video’s timecode. The TED site used a tags to mark each phrase, with inline JavaScript triggering the playback of the clicked link. This is functional when JavaScript is enabled, but fails when JavaScript is disabled, leaving you with a ton of bloated markup that doesn’t work:


<p>
<a href="#" class="transcriptLink" onclick="seekVideo(0); return false;">One way to change our genes is to make new ones,</a> 
<a href="#" class="transcriptLink" onclick="seekVideo(2000); return false;">as Craig Venter has so elegantly shown.</a>
</p>

Bruce’s span tags, on the other hand, are semantically sound — a span is a neutral, unobtrusive inline element meant to be a child of a block element such as p. Perfect. But wait, there’s more! Since this was an HTML5 demo, Bruce took advantage of the new data attribute that can be used on just about any HTML element. (The short version is: you can create any custom attribute you want, so long as the name begins with data-.) Bruce decided to create two attributes for each span: data-begin, which indicates (in seconds) when the phrase starts in the video, and data-end, which indicates when that phrase has ended in the video. Simple as can be, and extremely efficient:


<p>
<span data-begin=1 data-end=6>Hi, my name's Dr Archimedes Einstein 
and I'm a Dctor of Science at the University of Science</span>
</p>

Enter: EasyCaptions

I was incredibly inspired by these two pages and decided to combine their features, creating a new system I call EasyCaptions. The goal of EasyCaptions is to make it as simple as possible to add useful captions to your online videos. I want to eliminate the headaches of captioning as well as the excuses (too hard, confusing, etc.).

What EasyCaptions does:

  • Dynamically generates a div under your video that will display caption text (the div‘s style and positioning is completely configurable via CSS).
  • Dynamically makes each span in your transcript clickable, jumping to that point in the video. This is done via progressive enhancement and event delegation, leaving your markup clean and avoiding heavy-handed use of onclick.
  • Works out-of-the-box with HTML5.
  • Includes HTML5 video support detection, enabling you to use a Flash-based fallback if you desire.
  • Provides a hook for Flash-based fallback systems, enabling the captions and transcript to behave identically to the HTML5 version.

What you’ll need to do:

  • Type up the transcript of your video, using <span> tags to wrap each phrase, just like Bruce’s example above.
  • Place the transcript in a container element with a unique ID (such as div id="transcript").
  • Add a teeny bit of JavaScript (about 4 lines).

The final product. Successfully tested in Firefox, Safari, Opera, and Internet Explorer (IE and older versions of the other browsers all use a Flash Fallback if provided).

Peruse the test suite to get an idea of how flexible the system is.

The documentation and downloads are located on the EasyCaptions page.

CustomInput Class: Accessible, Custom-Styled Checkboxes and Radio Buttons

I’m a big fan of the Filament Group’s UI work.  They put a lot of thought into their work, and ensure everything they make is not only beautiful, but as accessible and as semantic as possible.

One of my favorite pieces of work by the Filament Group is their approach to stylized checkbox and radio <input> elements, as described in their post Accessible, Custom Designed Checkbox and Radio Button Inputs Styled with CSS (and a dash of jQuery)

The system is remarkably well-constructed, degrades gracefully, and is completely accessible if JavaScript, image loading, or CSS is disabled can’t be loaded. No small feat. Plus it remains semantically sound, with no bloated markup.

Having said all that, I’ve never actually used any of Filment Group’s UI code in my projects because of one little obstacle: they rely on jQuery.  Mind you, I’m not a jQuery hater, but I prefer MooTools and build all my major projects using MooTools. Switching to jQuery for such a small UI customization is not going to happen. I’ve often thought it would be great to build a MooTools version of Filament’s UI examples, but never had the time… until today.

I’m currently working on a new quiz system at work, and decided I’d incorporate Filament’s wonderful stylized checkboxes and radio buttons into my project, which meant it was time to roll up my sleeves and code me some Moo. 

View Demo

I made a couple of changes to the underlying JavaScript to suit a MooTools approach (and add some flexibility with the CSS selectors) but the basic premise is the same as Filament’s demo.

The following JavaScript will style ALL checkbox and radio inputs on your page. Note that CustomInput returns the collection of elements that have been styled.


window.addEvent("domready", function(){ 
    var all_styled_inputs = new CustomInput();
});

If you want to target specific parts of the page or only certain input types, pass a CSS selector as an argument:


window.addEvent("domready", function(){
    //Only style checkboxes
    var styled_checkboxes = new CustomInput("input[type='checkbox']");

    //Only style radios in a div named "walkman"
    var styled_radios = new CustomInput("#walkman input[type='radio']");
});

The CustomInput class has been fully JSLinted, and remains very close to the original jQuery version’s size. When compressed (YUI), it squeezes down to about 1.6kb. It uses ‘dollar-safe’ mode for compatibility with other JS libraries.

It has been successfully tested in the following systems:

Windows XP

  • Internet Explorer 6
  • Firefox 3.5
  • Safari 4
  • Chrome 4
  • Opera 10

Mac OS X (10.6.2)

  • Firefox 3.6
  • Safari 4
  • Opera 10.1
  • Chrome 5 (beta)

View Demo | Download Project Files

Major kudos to Filament Group for sharing their ideas with the world.

Update 3/12/2010: Fixed a typo in the JS file preventing the checkedHover class from being assigned.

Target settles accessibility lawsuit for $6 million

Think accessibility isn’t a big deal, and is only one of those issues “the other guy” has to deal with?

So did Target. And now they’ve lost $6,000,000 because of it.

In case you hadn’t heard, Target was sued by the National Federation for the Blind because its website was inaccessible for visually-impaired web surfers. At issue in the suit was whether the same accessibility standards for brick-and-mortar stores applied in cyberspace. The verdict: yes, most definitely. The suit became a class-action lawsuit, and yesterday Target settled the case, agreeing to establish a $6 million fund to pay out settlements.

Any web developer worth their salt will tell you this situation was completely avoidable.  Roger Johansson, Derek Featherstone, and Jeremy Keith (among many, many others) have been advocating progressive enhancement principles that prevent this kind of inaccessibility for a few years now. It’s amazing to me that companies as big as Target have effectively said “so what?” to such a significant number of potential customers.

Accessibility in e-learning

As an e-learning developer, I spend a lot of time wondering how the various learning management systems (LMS) have managed to skate by accessibility requirements. In my experience, almost every LMS I’ve seen uses outdated coding techniques (or over-the-top ajax) that make their system partially, if not completely, inaccessible. I often go through great pains to make my courses as accessible as possible, only to be forced to load them into a completely inaccessible LMS.

If U.S. Federal law (Section 508) requires federally-funded websites to be accessible, doesn’t that include many educational websites and web services such as LMSs and online courseware? Section 508 is ten years old already… why are so many of our LMSs and courses as inaccessible now as they were in 1998?

Probably because developers who code with accessibility in mind are still considered specialists in a small niche, when we should really be at a point where they’re a dime a dozen. Accessibility best practices should be a no-brainer, taught in entry-level web development classes alongside standardized (x)HTML markup and valid CSS.

Accessibility is essentially a non-conversation in e-learning. LMSs rarely use accessibility as a selling point, and e-learning course development tools often completely ignore accessibility (especially the Flash-based tools). This has to change, but as we all know, until there’s strong pressure or some kind of impetus to change, nothing will happen.

  • There are very few technical standards in e-learning besides SCORM, and SCORM doesn’t address accessibility; thus there is no technical enforcement for accessibility standards.
  • The e-learning development industry hasn’t felt pressure in the marketplace, so there’s no financial incentive. (Quite the opposite, actually; the industry has been leaning more and more towards inaccessible Flash-based courseware, hoping that Adobe will save the day by making Flash more accessible.)
  • The Feds haven’t really been enforcing 508 (I bet very few Fed employees even understand accessibility well enough to know what to look for), so there’s not much government pressure.

Eventually a big player in the e-learning field is going to get slapped with a lawsuit just like Target did. If that’s what it takes to wake people up, I’m hoping it’s sooner rather than later!

Link: Web Accessibility Checklist

The talented Cameron Moll has posted a link to a Web Accessibility Checklist prepared by Aaron Cannon, a (blind) member of his web development team.

Aaron’s checklist is an easy-to-understand list of accessibility dos and don’ts. Most of these are so simple and easy to implement that there’s really no excuse to NOT use them in your work!

Kudos to Aaron and Cameron for sharing this with the community!

WCAG Samurai Errata for Web Content Accessibility Guidelines (WCAG) 1.0 released

The WCAG Samurai Errata for Web Content Accessibility Guidelines (WCAG) 1.0 [link no longer available] were published this week by the WCAG Samurai group. They don’t contain anything I’d consider Earth-shattering, but there are some very solid guidelines that bring the 1999 WCAG 1.0 specs a little more in-line with our current state of the browser (no revelations on how to make ajax more accessible, though!).

Check out the summary on the introduction page.

I found their information about the Brewer Palette [link no longer available] particularly interesting; Cynthia Brewer “conducted research into creating maps that people with colour deficiency (colourblindness) can read and understand.”

Roger Johansson has a nice explanation of why the Samurai group formed and published this Errata documentation.

Accessibility development tools

There are a great set links for free development tools (validation services, browser toolbars and plugins) posted on the Web Access Centre Blog today:

Looking for alternatives to Bobby and WebXact? Try these!

Anyone familiar with accessibility should already know about Cynthia Says and a few of the web-based validation services… what I was impressed with were the links for the browser add-ons, specifically the Web Accessibility Toolbar for IE. It’s very similar to Chris Pederick’s popular Web Developer Toolbar extension for Firefox (which I use religiously), and is a nice upgrade from Microsoft’s ho-hum IE Developer Toolbar. Lastly, Jon Gunderson’s Firefox Accessibility Extension is another great Firefox add-on.

Check out the other links mentioned in the blog post, and the Web Access Centre’s site when you have time.

Development standards for e-learning… a starting point

Understanding that we should be using standards and best practices throughout e-learning development, the question becomes “what standards and best practices should we follow?”

Here’s my attempt at outlining some basics. Please feel free to suggest additional items in the comments section.

Follow established “web” best practices.

Separate presentation from content as much as possible by using Cascading Style Sheets and semantic (X)HTML markup.

  1. Use classes instead of inline styles or font tags.
  2. Avoid tables for layout purposes, except when presenting tabular data.
  3. Keep your markup semantic by properly using available elements: h1, h2 and h3 for headings, p for paragraphs, div for block-level content divisions (similar to fieldset in forms), and span for inline classes. Don’t be afraid to try lesser-known elements such as acronym for acronyms, dl for definition lists, and cite for citations!
    1. Note: although div is heavily used in CSS-based layouts, you should try to avoid overuse of the div element. Bloated markup is unsemantic and ugly.
    2. Avoid direct copying and pasting from Microsoft Office products, as this tends to insert bloated Microsoft-specific HTML.
  4. Avoid deprecated or browser-specific elements such as blink and marquee.

Separate behavior from content as much as possible by using unobtrusive JavaScript techniques.

Even if your course depends on JavaScript being available, this is a good practice to follow.

  1. Don’t use inline scripts. Keep all scripts in the head of your document or in an external .JS file.
  2. Use a lot of error checking throughout your scripts. This helps ensure that if an error occurs, your script should fail gracefully, and you should be able to diagnose the problem more easily.
  3. Avoid using JavaScript where it isn’t needed. CSS is capable of handling many chores once assigned to JavaScript, such as image-based mouseovers and “hover” or “dropdown” menus. CSS has the added bonus of processing the chore much faster than JavaScript, too!
  4. Avoid using the global space. With the proliferation of JavaScript in our “Web 2.0” world, web pages use multiple script libraries and customs functions. Avoiding using the global space by using faux “namespacing” (object literals) can greatly reduce the odds of your script conflicting with another script.

Avoid plugins and browser-specific technologies as much as possible

  1. Don’t use Microsoft’s ActiveX or the Windows-specific FSCommand. Stick to cross-browser and cross-platform solutions.
  2. Avoid Java and any other format that requires a plugin, especially one that requires a large download. Flash Player may be the only exception due to its incredibly high saturation rate, but even then you should plan ahead in case users don’t have Flash Player available.
  3. If a plugin is required, especially an unusual or uncommon plugin, be sure to notify the user of the requirement before they launch the course.

Keep content as accessible as possible by following established accessibility best practices.

  1. Avoid tables for layout purposes, except when presenting tabular data.
  2. Avoid using images for important navigation elements. Your markup will be cleaner (and you’ll be separating your style from content) by sticking to text-based navigation links. Don’t worry — you can still use images by utilizing CSS image replacement techniques! If you decide to use images in your markup, be sure to include useful descriptive text in the alt attribute.
  3. Be aware of tab order; don’t mess with the tab order of page elements unless it’s absolutely necessary.
  4. If your page contains lots of navigation menu items, give the user a ‘skip navigation’ option. This is especially important for people who use screen readers.
  5. Ensure links contain useful text such as “Click here to continue” or even “continue,” not the more obscure “click here.”
  6. Heavy use of onmouseover and onclick in JavaScript can cause problems for people who don’t use a mouse (many people use their keyboard for all navigation purposes). Be aware of the repercussions of your coding techniques.
  7. Try testing your course in a popular screen reader such as JAWS.
  8. Rich media such as Flash videos are fine to use in your course. However, there are some simple steps you can take to ensure your Flash content is as widely accessible as possible:
    1. Use fallback (popularly known as “alternate”) content in your HTML in case Flash is not available. For instance, if your page contains a Flash video, include a text transcription in the HTML. When Flash isn’t available, display this transcription automatically (SWFObject is great for this purpose).
    2. If using video, screencasts, or any other media that contains audio narration, include a closed-captioning option or a link to a text transcription.
    3. Adobe has made strides to make Flash SWFs more accessible. Keep up with the latest trends, and use Flash best practices to ensure maximum accessibility.

Keep your courseware portable.

  1. Avoid server-side dependencies such as Active Server Pages (ASP), PHP, and databases.
  2. Use standardized LMS communication protocols such as SCORM and AICC. Avoid using proprietary course-to-LMS communication methods as they make content migration and reusability a very difficult task.
  3. Avoid using remote content if possible. Some systems may not be able to access the remote content due to security or connectivity issues, which could lead to a broken course.

Ensure your course has a long shelf-life and is easily maintainable.

  1. Avoid uncommon development platforms and/or proprietary file formats whenever possible. This ensures your content will remain editable for the foreseeable future.
  2. Clearly annotate/document your development process and home-brewed scripts. This ensures future team members and/or contractors will be able to work on the project if needed.
  3. If you compile or compress your files, be sure to keep a commented, uncompressed copy of each file with your development files. This applies to both JavaScript and Flash-based projects.

What do you think?

Let’s have a conversation about this. I’m 100% positive I’ve missed a few things, and I’m pretty sure not everyone will agree with my statements. Why not join in and add your two cents? I’ll leave the comments section for this topic open indefinitely.

Why don’t more e-learning developers use standards?

Question: Why don’t more e-learning developers use standards?

I don’t know for sure, but I have a number of guesses. Here’s a quick list off the top of my head:

  • Lack of knowledge about standards
  • Confusing or obtuse documentation
  • Competing standards
  • Misconceptions about cost effectiveness
  • Difficulty / Lack of support in development tools

This is a sort of stream-of-consciousness post, so I’m sure I’m missing a few things. Feel free to add your two cents.

Lack of knowledge about standards

It’s my opinion that a large number of e-learning developers are non-technical, or are mid-level techies who came into the field from other areas. Not having a background in web development, many of these developers probably don’t know that using tables for layout purposes is a faux-pas, or realize the power of well-written CSS. Many of these developers probably rely on their e-learning development tools to handle that stuff for them.

And for those who know all about web standards, e-learning standards are a whole ‘nother beast. Being a master with CSS doesn’t mean you’ll easily grasp the depths of SCORM’s murky sequencing features. Which leads us to…

Confusing or obtuse documentation

I like SCORM. I also hate SCORM. Such is life.

There are a number of proposed standards for e-learning courseware, with SCORM and AICC probably leading the way. However, AICC is considered out of date, and SCORM is considered difficult to use. As with many proposed standards, I believe SCORM’s steep learning curve lies largely in the really hard-to-read documentation and unclear examples.

My apologies to those who wrote the documentation — I do think it’s very thorough — but for someone who isn’t familiar with SCORM, trying to get a handle on it by reading those documents is a very frustrating experience. I think Claude Ostyn’s Cooking Up a SCORM and Eye of the SCORM documents were the most reader-friendly SCORM documents available, but with his unfortunate and untimely passing, they probably won’t be updated.

Competing standards

SCORM isn’t the only standard out there. As some of you may recall from my previous post, the IMS Global Learning Consortium (among others) has created a number of proposed standards for the world to use, including the IMS manifest (which accompanies every SCORM course), the Question and Test Interoperability specification, and most recently, the ultra-secretive Common Cartridge proposal.

Having tried my hand at using these IMS standards, lemme tell ya, they are not easy or fun to use. Big disincentive from the start. (The IMS takes inconvenience one step further by making it difficult to even figure out exactly what their standards are.)

The IMS is working on the Common Cartridge Alliance. According to some, it’s a SCORM killer that will revolutionize e-learning courseware.

However, SCORM is much more established, and has been adopted by every major LMS vendor. Assuming the Common Cartridge is as good as promised (and the specification ever becomes publicly available), it will force developers to choose sides.

Backing off of e-learning standards for a minute, what about other competing standards? There are no shortage of standards to choose from: HTML 4 versus XHTML 1.0 (and soon HTML 5 versus XHTML 2.0); Internet Explorer (and its proprietary ActiveX controls) versus Firefox/Safari/Opera/et al, Adobe Flash versus the new kid on the block Microsoft Silverlight, etc.

Making sound choices involves homework on the issues. Oftentimes, I think people make their choice based on ease of use (“does my WYSIWYG editor support it?”) or cost. This is a fair point; after all, we can only do what our budgets allow, right? Well…

Misconceptions about cost effectiveness

One of the biggest arguments against standards and best practices is the amount of time it takes to get up and running with standards.

When it comes to web standards such as valid XHTML markup and CSS-based layouts (separating content from presentation), I think a small amount of time getting acquainted with the techniques pays big dividends in the long run. When using standards and best practices, you’ll spend less time troubleshooting browser compatibility, less time updating the look and feel (external CSS makes it so much easier!), and less effort making the course work in different mediums (standard web browser versus mobile versus text reader, etc.).

Using standards also ensures your courseware will have a longer shelf life.

It’s too expensive to NOT use standards and best practices.

Difficulty / Lack of support in development tools

A hot topic of late is the quality and capabilities of e-learning development tools. Personally, I don’t use them very much except for special needs, such as making animated screen captures in Captivate and/or Camtasia. I normally stick to standard web development tools such as Dreamweaver and Flash Professional.

However, I totally understand the needs of many others out there who don’t have the time and/or expertise to make courseware from scratch; there’s a reason the e-learning development tool field has really bloomed the last few years, and it won’t slow down anytime soon.

But as I’ve mentioned before, these tools most often do not support web standards or best practices. What’s worse, they often completely ignore standards while making the purchaser/user of the software think they’re getting top-notch, state-of-the-art stuff. It’s false advertising, but it’s also effective marketing. Very effective.

I wish the e-learning tools market would shape up and self-regulate! (Riiiight…) Hey tool developers: Use standards because they matter. Use best practices because they’re best practices for a reason. If you incorporate standards and best practices in this young niche market, you could very well find yourself top-shelf in a matter of months. If you were already top-shelf, you could become uber-elite. Think about it.

So what can we do?

I know I keep espousing standards without really giving enough concrete know-how and direction. Honestly, I’ll be the first to admit I don’t have the answers — but maybe together we can do something about it. I’m proposing we create a community-defined set of simplified e-learning development standards that can be viewed more as ‘rules of thumb’ than law.

For starters, a standard like SCORM is very intimidating because of its intricacies and density. Claude Ostyn’s writings were enlightening if only because the first thing he did was show an extremely simple example of a single-page course. His point was that just because SCORM can be used in-depth doesn’t mean it has to be. We can just use it for what we need and ignore the rest. A great example is SCORM’s page sequencing and navigation system; it’s really tricky to figure out, and requires a really complicated imsmanifest.xml file. If your course only has a few pages, or if you already have a decent navigation system worked out, don’t use SCORM’s navigation features. You can still create a SCORM-conformant course (SCO) that will work with any SCORM-conformant LMS!

Got ideas?

So how about it? I’m going to start writing down simple, easy-to-digest rules of thumb that I hope someone will find useful. I intend to provide examples and/or links with every concept. Will you help me? Maybe together we can get this thing turned around.