Making e-learning accessible

By: Steven Price

In case you haven't noticed, accessibility has become a major issue for e-learning. Under the Disability Discrimination Act, organisations have a legal responsibility to make "reasonable adjustments" in order to make their products and services accessible to people with disabilities. And this now includes all forms of software.

As a developer of e-learning content, we started to look into accessibility over two years ago. At the time, we thought we'd be able to right the accessibility wrongs of the e-learning world within six months. How wrong can you be? The months have turned into years, during which time our journey has turned into something of a Star Trek voyage of discovery - minus the drama, excitement and tight latex body suits.

In this article, I'll outline the main problems associated with developing accessible e-learning, and some of the approaches that can be taken to overcoming these. As you'll see, producing accessible e-learning is by no means as straightforward as it might - and perhaps should - be, but with a bit of effort it is possible to go a long way to meeting the needs of many disabled people.

Accessibility: the challenges

So why exactly is accessibility such a challenge when it comes to e-learning? Well, first and perhaps foremost, it's because disability is a complex area. Ask most people to define disability and the chances are that wheelchairs will feature prominently in their responses. Even the icon used to represent disability is usually a wheelchair! The reality is, though, that just 5% of disabled people actually use a wheelchair. The term "disability" covers a broad range of conditions and different disabled people have different needs and requirements.

Just as the broad scope of "disability" is a major challenge when it comes to creating accessible e-learning, so too is the lack of integration in accessibility technology. For many years now, a number of software packages have been available that read out the contents of the screen in a synthesised voice. These "screen readers" as they're known enable visually impaired people to use computers. Initially, screen readers were pretty hit and miss affairs, working with some programs, but not with others. Recently, however, Microsoft implemented Active Accessibility (MSAA) into its operating systems. This provides a standard communication interface between any program and any MSAA compliant screen reader, offering the tantalising prospect of consistent screen reader support in all programs.

"Great stuff!" you might be thinking (well, we certainly did anyway). The only problem is that none of the bits seem to fit together very well - at least, not yet. We use Macromedia Flash to develop most of our e-learning courses, and since version 6 this has supported MSAA-compliant screen readers. However, building interactive Flash content that works well with screen readers can sometimes feel about as easy as roller blading up Everest. We've resolved most issues we've encountered, but it's taken a long time and we still get radically different results under different screen readers (more on this later).

So far we've concentrated on external factors that can get in the way of creating accessible e-learning. But there's another major challenge that stems from the nature of the e-learning medium itself. Simple HTML web pages are fairly static, linear sequences consisting of text, links and the odd image: bread and butter stuff for any self-respecting screen reader. Good e-learning, on the other hand, is dynamic, interactive and incorporates a range of media elements. It's one thing to get a screen reader to read out a news story on a web site, but where do you start when you're building a screen that incorporates an audio soundtrack, a video clip, text and a multiple choice question with branching feedback?

Now some people have taken the view that all of this justifies simplifying e-learning so that it's less dynamic, interactive and media rich. Trouble is, these are precisely the elements that make e-learning effective; without them, "e-learning" becomes little more than "e-page turning". Given this, we decided very early on that our objective wasn't to achieve accessibility by sacrificing the effectiveness of the e-learning experience, but rather to look for ways of making effective e-learning as accessible as possible. More difficult, but ultimately more rewarding all round.

Approaches to accessibility

At this point, you might be starting to think that creating accessible e-learning is the stuff of nightmares. And to be honest, there are times when I've felt the same. However, it's not all doom and gloom! Despite all the problems, limitations and frustrations (not to mention lost sleep and grey hair), it really is possible to develop effective e-learning content that's accessible to disabled people.

In this section, I'll outline some of the approaches we've taken to addressing the needs of people with different disabilities. In order to do this, I'm going to categorise disabilities under three main headings:

• Visual impairments, encompassing people who are blind or who have difficulty seeing things clearly.
• Hearing impairments, encompassing people who are deaf or hard of hearing.
• Dexterity impairments, encompassing people who have difficulty manipulating or controlling things.

We've found that viewing disability under these three broad headings is a big help when it comes to developing a well-rounded accessibility strategy.

Visual impairments

The key thing to keep in mind here is that "visual impairment" does not mean "blind": there are a whole range of conditions that fall far short of being totally blind, and a good accessibility strategy should reflect this.

The first base when it comes to meeting the needs of visually impaired people, is ensuring the e-learning content is compatible with screen readers. As I mentioned earlier, this is often easier said than done, particularly when it comes to complex interactive screens (e.g. drag and drop questions). However, with a bit of effort, we've found that it is possible to develop interactive Flash content that works well with MSAA-compliant screen readers. Here are some of our top tips:

• Research how visually impaired people use screen readers and user test your courseware. You can do this by getting in touch with organisations such as the Royal National Institute of the Blind (RNIB) or the Royal National College for the Blind (RNCB). Our courseware has been reviewed by both the RNIB and RNCB and they raised a number of important issues which we've now addressed.
• You'll get different results under different screen readers (ain't standards a wonderful thing!) To avoid going round in circles during development, choose one screen reader to develop against. We'd currently recommend the latest version of JAWS, as it's the most widely used and seems to handle Flash content better than the others. However, it's worth reviewing this each time different versions of Flash, MSAA and the screen readers themselves are released.
• Always try to develop screens so that the content gets read out in a logical narrative order. Don't just develop screens so that things get read out in the order they physically appear on the screen.
• As a preliminary test of how well your content works with a screen reader, try running through everything with the monitor turned off. You'll be amazed at the issues you uncover the first few times you do this!

While it is possible to build Flash content that works well with screen readers, there are currently limits to how far you can take this. Recently, we developed a course that incorporated a series of highly interactive games. There was simply no way of making these work with a screen reader, so we implemented our own text to speech program, FreeSpeech. We have complete control over this from within Flash, which enables us to communicate any information to the user at any time.

In addition to all of the above, we've also found that the following features can be helpful for visually impaired people:

• Dynamic content scaling: if the user resizes the browser window, the Flash content automatically re-scales to fill the window. On larger monitors, maximising the browser window can substantially increase the size of all visual elements.
• Content magnification: users can select a zoom tool to magnify portions of the screen, e.g. in order to read a small label on a graphic.
• Font size selection: in some of our courses, we've allowed users to choose between a standard and large font. In order to accommodate this, we've had to take a simpler approach to the visual layout of some screens, but this is a relatively small compromise if scaling and magnification aren't considered to provide an adequate level of accessibility.
• Alternative colour schemes: in our most recent courses, we've given users the option of choosing between alternative colour schemes. This can also make the content more accessible to, for example, people with dyslexia.

Hearing impairments

Again, the first thing to keep in mind is that "hearing impairment" doesn't necessarily mean "deaf". In the early days of e-learning, audio was very rarely used to deliver content, but as bandwidth has improved, this has changed.

Here are some of the approaches we've taken to meeting the needs of people with hearing impairments:

• Subtitles: these can be turned on and off by the user and work in the same way as the subtitles on TV programmes. Subtitles work really well because they take up minimal screen real estate and enable content to be delivered in a highly dynamic way, e.g. visual media elements can be synchronised with the audio in order to amplify key learning points.
• Audio transcripts: in many of our courses, users can select to view a full transcript of all audio on each screen.
• Duplicating audio with text: in some courses, we've duplicated all audio with on screen text. However, I have to stress that this isn't ideal: the text requires a lot of screen real estate and this inevitably results in less dynamic and visually engaging content. For these reasons, we usually only recommend this approach when a course needs to be available in both a text and audio format (e.g. because certain users may have limited bandwidth), but there isn't the budget to develop separate text and audio versions.

Dexterity impairments

Some people have difficulties using standard computer input devices, such as the keyboard and mouse. To maximise accessibility levels, it's important to ensure that all functionality can be accessed using either the keyboard or mouse. With a bit of forethought and planning, we've found that dual control is usually pretty straightforward to implement, even on complex interactions. Implementing shortcut keys for frequently-used functions (e.g. navigating between screens) is another good idea, and can make your courses more usable for everyone.

Recently we've also been experimenting with speech recognition. This is built into Windows XP and, with a bit of nifty programming work, can be activated in the e-learning content, enabling users to work through courses using nothing more than a series of voice commands, e.g. "Next" to move on to the next page, "Select" to press a button, etc. We've got some very positive results so far, but it's early days, so watch this space!

And finally...

I hope this article has succeeded in communicating both the challenges associated with developing accessible e-learning, and some of the practical ways in which each of these can be overcome without - and this is key - reducing the quality or effectiveness of the learning experience.

Of course, none of the approaches we've discussed are 'magic wand' solutions - they all require implementation and some can significantly increase both development and testing timescales. However, with good planning and development techniques, we've found that these extra overheads can be minimised.

About the author:

Steven Price is Managing Director of bespoke e-learning development specialists, Cylix. To find out more, email steven.price@cylix.co.uk.

| Return to Articles index |