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!

Advertisements

Does SCORM need a little brother?

For many involved in the SCORM 2.0 project, the hope is that we can transform the SCORM 1.x caterpillar into a SCORM 2.x butterfly; that the gestation period of SCORM 1.x has ended, and soon SCORM 2.0 will emerge from its cocoon and dazzle the world with its beauty and agility.

What’s worrisome is that there appears to be a divide in the SCORM 2.0 community between the pro-aggregators and the non-aggregators, and from the looks of it, this divide will ultimately leave one side of the aisle unhappy.

Pro-aggregators

If there’s one thing I’m learning by reviewing the SCORM 2.0 white papers submitted to LETSI, it’s that the SCORM community is full of hope and ambition when it comes to truly reusable course objects. There are some really interesting ideas being proposed for SCORM 2.0 — especially as relates to social networking and Web 2.0 technology — and some folks are swinging for the fences. The biggest fear I sense from this group is that SCORM 2.0 won’t be aggressive enough when it comes incorporating new ideas or fixing the aggregation issues in SCORM 1.x, most notably sequencing and navigation.

Non-aggregators

The SCORM community is also full of e-learning developers who do not use aggregation, and are really in no hurry to try it. Yes, I’m one of them.

Hi, my name is Philip, and I don’t use content aggregation for my e-learning courses.

My SCORM 2.0 white paper [link no longer available] focused on the notion of keeping things simple, easy to use, and accessible. Content aggregation and the related issues of sequencing and navigation are by nature complicated and difficult to manage.

From my vantage point, it appears the vast majority of e-learning developers producing SCORM-enabled courses do not use aggregation, and choose to package their courses as all-in-one SCOs. I believe this is largely for two reasons:

1. Most commercial e-learning development software (Adobe Captivate, Articulate Presenter, Rapid Intake ProForm, Trivantis Lectora, etc.) do not natively support multi-SCO courses; they publish courses as self-contained non-shareable packages.

2. Most e-learning developers do not have the infrastructure, time, funding, management support, etc. to develop courses that use/reuse shareable content objects. This has no bearing on whether they think SCOs are a good idea — almost everyone sees the value in a true SCO world — it just means it isn’t practical for them at this point in time.

SCO what?

So if non-aggregators don’t use SCOs, what’s the point in using SCORM in their courseware? Simple: it’s the easiest way to guarantee basic course functionality and interoperability. They want to know their course will work in any LMS and has a standardized data repository for course data, including quiz results and bookmarking.

He’s not heavy, he’s my brother

Judging by the topics in the SCORM 2.0 white paper submissions, the pro-aggregators are currently the most vocal members of the fledgling SCORM 2.0 community. Non-aggregators are the (somewhat) silent majority. This is bound to cause some angst. I think there’s a way to keep both sides happy: spin off the communication element of SCORM (the SCORM RTE API) as a standalone standard.

Again, we must remember that SCO stands for shareable content object. If a course is not built to be shareable, it isn’t really a SCO, even if it uses SCORM for packaging. Spinning the communication element off into its own standard — without the name SCORM — would free SCORM to truly be a Shareable Content Object Reference Model, and would free non-aggregators from having to deal with the complexities of SCORM.

This would also allow the group responsible for the new communication standard to really dig in to the communication methodologies (ECMAScript API versus web service, etc.) without having to spend resources on other topics, such as content sequencing.

The biggest question would be: What should we call the new communication standard? I think we should use the name Course Content Communication Protocol (CCCP). That way the original sponsors of SCORM — the American government and military-industrial complex — would have to officially endorse the CCCP!

[Link for those who don’t get the joke.]

All kidding aside, I do believe we should consider removing the burden of the communication protocols from the SCORM 2.0 workgroup and let the discussions about SCORM 2.0 focus on aggregation. I’m sure I’m not the only one who feels this is a viable option; if anything, I imagine the companies that produce rapid e-learning development tools would be very interested in freeing themselves from SCORM while maintaining a high level of course interoperability.

ECMAScript vs JavaScript vs ActionScript: Do you know the difference?

If you’re trying to use SCORM in your e-learning, you’ve undoubtedly heard of JavaScript and ActionScript. But do you know the different between ECMAScript, JavaScript, and ActionScript?

Alex Russell has provided definitions for many of the ECMAScript-related names you might be reading about these days, including ECMAScript (3, 3.1, 4), ActionScript 3, Harmony, and JavaScript 2.

Very helpful!

Via Ajaxian.

Standards don’t foster innovation, they codify it

After all my ruminating on SCORM 2.0 the last couple of weeks, it was interesting to read about the latest news regarding the ECMAScript standard.

It was even more interesting to read some of the reactions, including those from Adobe’s Dave McAllister [link no longer available] and Yahoo’s Douglas Crockford. I swear this passage from Crockford could have come directly from one of the SCORM 2.0 discussions:

The success of this project will depend on the ability of TC39 to do a better job of managing the tradeoffs between innovation and stability, and adopting a discipline for managing complexity. Simplicity should be highly valued in a standard. Simplicity cannot be added. Instead, complexity must be removed.

It turns out that standard bodies are not good places to innovate. That’s what laboratories and startups are for. Standards must be drafted by consensus. Standards must be free of controversy. If a feature is too murky to produce a consensus, then it should not be a candidate for standardization. It is for a good reason that “design by committee” is a pejorative. Standards bodies should not be in the business of design. They should stick to careful specification, which is important and difficult work.

Just substitute LETSI for “TC39” and you have a very relevant, poignant piece of advice for the SCORM 2.0 workgroup as it moves forward.

A common thread in many of the posts I’ve been reading is that standards do not lead to innovation, but rather that innovation leads to standardization. Adobe’s Mike Chambers has a great compilation of comments on this topic. I especially found this quote on standards from Dojo’s Alex Russell to be very insightful:

we need to applaud and use the hell out of “non-standard” features until such time as there’s a standard to cover equivalent functionality.

LETSI has promised to foster innovation. Will LETSI attempt to codify innovative and non-standardized technology or practices into a standard? Will it only accept existing standards (royalty-free standards, at that)?

The Raising of SCORM 2.0 will be interesting to watch as it plays out.

SCORM 2.0 white paper submission

I submitted my white paper for SCORM 2.0 today. I don’t see it listed on the LETSI site yet, but I’m hoping they received it and that it will be added soon. 🙂

I wanted to share a few things about my experience writing that paper. First of all, it wound up being a very informal paper, and doesn’t really follow the structure the LETSI folks had requested (sorry, guys). I went through a number of false starts (about seven, I think) trying to nail down what I wanted to say; even now that I’m finished, I still feel like I didn’t quite express everything I wanted to say. SCORM is just so… nebulous, and the potential for scope creep with SCORM 2.0 is so strong that I had a hard time keeping my comments focused and concise.

In the end, I wound up writing something of a ‘stream of consciousness’ paper that mostly served to get some of my concerns and notions on the official record. When I see the scholarly work some of the other participants submitted, I feel rather embarrassed, but hey, such is life!

Speaking of other papers, I took the liberty of reviewing many of the submitted documents, and I must say, I’m impressed! There’s quite a range of material and opinions, and it looks like there’s some very interesting ideas in there. From what I can see, SCORM 2.0 might wind up being a simplified and cleaned up version of SCORM 2004, or it may be a completely different animal consisting of all kinds of new features supporting the latest trends in e-learning and web technology.

I especially agreed with one of Mike Rustici‘s points:

The ‘burden of complexity’ [should be] on the LMS developers. […] It only makes sense that the LMSs should have to do the hard work and that SCORM should be nearly transparent to content developers.

This goes along with my primary motivation: make SCORM easier for content developers! Otherwise no one will want to use it and it will become useless and will be replaced by proprietary workarounds. As Rustici says, “Sequencing needs to be simplified so that it is easier than creating your own alternative.” I say this is true for all of SCORM, not just sequencing.

White Paper Addendum

Here are a few odds and ends I left out of the paper that I think are worth putting on record. These are in addition to my previous suggestions for SCORM 2.0.

A lite API. If content aggregation remains part of the core spec, can we implement a ‘lite’ API that simplifies SCORM use for single SCO courses? (The reasoning being that single SCO courses shouldn’t be forced to use full manifests and other heavy configuration items that aggregated courses will require)

SCORM security via a Web service. One potential benefit for using a web service for SCORM in lieu of a ECMAScript API is security; ECMAScript is inherently insecure, and a web service (depending on the communication protocol being used) may be easier to encrypt and protect.

Frames and session states. I my paper, I only mentioned this topic in passing, but it’s worth fleshing out a little bit.

SCORM’s current ECMAScript API requires an active JavaScript connection with the course; If the course’s connection to the SCORM API is lost, the course can’t exchange SCORM data with the LMS, effectively killing the course’s tracking functionality. Any time a webpage is unloaded in the browser, that page’s JavaScript is terminated. This is a simplistic explanation, but the point is that the browser won’t allow JavaScript to maintain a session across pages. (A session is data that persists from page to page as a user navigates through a website.)

To get around this limitation, websites often use some trickery. The most common workarounds are:

  1. Traditional framesets
  2. iframes
  3. Flash

The frameset workaround uses the parent frame to maintain session data; the parent frame never reloads, and thus never ends the session. All page loading/unloading occurs in a child frame.

The iframe workaround is much like the frameset workaround, except it uses a single inline frame instead of a full frameset.

The Flash workaround is simple: the HTML page contains a Flash movie that handles all content; the HTML file itself never reloads, allowing it to maintain a JavaScript session, while the Flash content does all the dynamic loading and unloading of content without impacting the HTML file.

Since SCORM requires an active JavaScript session to maintain communication with the API, most SCORM courses are forced to use one of these three workarounds. The problem is that all three of these methods have significant (and well-documented) usability and accessibility issues.

If SCORM 2.0 can implement some kind of Web service that eliminates the need for a JavaScript/ECMAScript API, we can also eliminate the reliance on these three workarounds. This will serve to make e-learning courses much more accessible, and reduce developers’ reliance on JavaScript.

Have you read any of the submissions?

If you’ve read any of the whitepaper submissions, I’d be interested to know which ones caught your eye or made the hair on the back of your neck stand up. And if you have opinions on the papers, definitely submit your comments to the LETSI site… they need all the feedback they can get. After all, SCORM 2.0 is for us; make sure your voice is heard!

Adobe Captivate 4 beta coming soon… testers needed!

An FYI for Adobe Captivate users: Adobe is about to release the Captivate 4 beta, and is looking for beta testers (no experience required).

This is a great opportunity to get a sneak peak at Captivate’s latest features and provide feedback about the product before it gets released to the general public.

In their own words: “We want as many of you as possible to actively test and help shape a rock-solid release.”

Sign up at adobe.com [link no longer available].

Choosing a specific technology for your e-learning courseware

This question came in via email. I figured I would post it (keeping the author anonymous) because these are very common questions, and maybe this post can help other people out. I also want to give others the opportunity to throw in their 2 cents! 🙂

The question(s):

I am trying to decide among three vendors for an e-learning project. Two of them are advocating using Flash/XML, Javascript, .swf files, etc. One is planning to use Toolbook for the development.

I am trying to decide the advantages of one method (rapid e-learning tool like Toolbook) over the other two (combinations of tools). I have a basic understanding of all of the technology, and I have been trying to research this (this is where I got your site), but I’d really like some non-vendor insight as to the pros and cons of one approach over the other.

This is a standalone e-learning course. It can be run through an LMS system, a web browser or if need be, we could distribute it on CD although we don’t forsee doing that. It needs to be SCORM, AICC, and 508 compliant.

Could you help me out? If you could advise on areas such as ease of translation and skills/tools needed to update later on as well, that would be great.

Choosing a tool/course file format

I don’t have enough time to get into the depths of the issue, but here are my gut reactions:

Toolbook.
Avoid Toolbook! It was a great program for its time, but it doesn’t work in a native Web format; anything created in Toolbook is Windows-only (no Mac compatibility). To create a course that works online — and with Macs — you’ll need to export the project to a Web-friendly format with reduced functionality. That’s a recipe for disaster these days. We bought a copy about a year ago — for ~$2000! — and have never used it because of these issues. Yuck.

Note: if anyone from SumTotal’s Toolbook team is reading this, I’d love to hear your thoughts; is the latest version any better? Is there new functionality I’m not aware of?

Flash/Flex with XML
This is a popular option, especially if you’re concerned about localization (XML files containing one language can be swapped with XML files containing other languages), but Flash is not particularly accessible and could potentially hurt your 508 compliance. Adobe is working on this, but they’re not quite there yet. Flash also has limitations when it comes to handling (and styling) large amounts of text.

Most e-learning vendors’ tools output to Flash SWF format; I think it’s probably for two reasons: Flash gives you a lot of control over the course (including the ability to easily add rich media such as narration or animations) and Flash is an easy way to avoid cross-platform (Windows versus Mac) issues.

(X)HTML with JavaScript
Personally, I lean heavily towards (X)HTML-based courses. HTML courses are much more flexible, accessible, and easy to update than Flash/Flex courses. Thoughts on HTML courseware:

  1. Flexibility: An HTML-based course is basically a web site with some extra JavaScript that can keep tabs on a user’s progress. As with any website, you can import almost any kind of rich media, including Flash animations, Captivate simulations, videos, images, music, quizzes, etc. Localization is a breeze because it’s HTML; by nature it can handle just about any language you throw at it. Wikipedia is a great example (though Wikipedia uses a database and PHP to handle the localization).
  2. Accessibility: HTML is much more accessible than just about any other course format out there (including Flash and Silverlight). Of course, the level of accessibility depends how the course is built; it’s up to your developer to be responsible and avoid pitfalls that can make your course less accessible. Heavy use of mouse events or xmlhttprequest in JavaScript, heavy use of rich media without providing textual equivalents, and bad development practices such as using table-based layouts and deep framesets can render an HTML page pretty inaccessible. If you import Flash SWFs on every page then you’re really no better off than you were if you just went all-Flash to begin with.
  3. Cross-browser/cross-platform: This used to be a huge barrier for web developers. Thankfully, with the emergence of Web standards and JavaScript frameworks over the last few years, things are much easier and more compatible than they used to be. Most of us are just waiting for IE6 to go away! 🙂

Delivery options

A couple of things to understand:

  1. SCORM and AICC are competing standards for course tracking/LMS communication… you don’t usually have a course that conforms to both, it’s one or the other. You can think of it as a choosing a cell phone provider: AT&T and Verizon both do roughly the same job, but with a few different ‘plan’ options. After weighing the differences, you pick the one that suits your needs (and budget). SCORM is newer than AICC and is currently the more widely accepted standard, but AICC still has a loyal following and is a viable option.
  2. SCORM/AICC tracking requires an LMS that supports one of those standards. You can’t use SCORM or AICC tracking from a non-LMS website unless someone has built a ‘lite’ LMS for you that implements a database and the API for SCORM or AICC. Likewise, SCORM/AICC won’t work from a CD-Rom.

If you need the course to be able to work (without tracking) from a website or CD-Rom, be sure to discuss it with the vendor beforehand.

Thoughts?

These were just my gut reactions to the questions. I’m sure a bunch of you have pretty strong feelings on the subject. Care to share?