Steven Price managing director of bespoke e-learning development specialists, Cylix explains the key issues to bear in mind when developing accessible e-learning.
Accessibility is now 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.
The challenges
Disability is a complex area. Ask most people to define disability and the chances are that wheelchairs will feature prominently in their responses. 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.
It’s useful to categorise disabilities under three main headings:
* Visual impairments, encompassing people who are blind 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.
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. 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 consistent screen reader support in all programs.
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.
There is another major challenge that stems from the nature of the e-learning medium – 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.
Approaches to accessibility
* 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, 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:
* You’ll get different results under different screen readers. To avoid going round in circles during development, choose one screen reader to develop against.
* 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.
* In order to test 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!
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.
* 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. I:n 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 build e-learning so 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.
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.
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.
