Creating accessible e-learning resources for disabled students.

2. Assessing accessibility

When developing e-learning content, make sure you continually check for potential accessibility barriers; certainly test before you introduce the resource with students. For many people, though, the most pressing task will be to assess existing resources for potential accessibility barriers. In either situation, there are a number of steps that can help.

An obvious step is to check the resource against accessible design guidelines:

• for web sites, the W3C Web Content Accessibility Guidelines (WCAG) are widely recognised as the definitive set of guidelines, and they provide a useful list of the checkpoints contained within the Guidelines.
• for e-learning content, the IMS Accessibility Guidelines for Developing Accessible Learning Applications also provide useful advice, although this resource is more a set of recommendations and resources than a structured checklist.
• for software applications, IBM’s Software accessibility guidelines are probably the most authoritative guidelines.

A manual check against guidelines does, however, require a thorough understanding of these guidelines and the technical aspects they address; for some the guidelines themselves can be a challenge to interpret. Several excellent automated web accessibility tools exist, which can check the code of web sites against recognised guidelines and report problems; some can even attempt to repair certain errors. Links to some useful tools are provided in the Further Resources section.

In some cases, the output of these tools can be overwhelming, and difficult to comprehend or act upon, and in any case they can only check against a subset of the full range of accessibility barriers – manual checking is also required.

In addition to a manual or automated guideline check, check the resource under different access conditions:

• using the keyboard only
• with graphics turned off (for web sites, this can be done by changing a browser setting, or better still, using a text only web browser such as Lynx -freely available at <http://lynx.browser.org>)
• for web content, with scripts, frames and style sheets turned off
• with speakers turned off
• without colour – a basic simulation is to print off a screenshot in a black and white printer – does all the information still make sense?
• a grammar and spell check helps to uncover any potential problems that might affect the quality of text-to-speech output.

For web resources, view them using a variety of different browsers. Can the information still be understood? Does all functionality still work?

Try to listen to the e-learning resource spoken by a screen reader or speech browser - does it make sense when heard aloud? If access to a screen reader is not possible, a text-only browser gives a useful approximation of the order in which the page content will appear. Have the resource assessed by disabled people with a variety of access needs.

Can the evaluators access and navigate the content of the resource? Can they use the resource to perform the tasks intended? Institutional disability support services may be able to help in identifying willing evaluators, but be prepared to recompense any helpers accordingly!

Another important step for web sites is to validate the HTML code used, with an automated validation tool – the World Wide Web Consortium’s MarkUp Validation Service is ideal for this purpose <http://validator.w3.org>.

In each evaluation stage, note down any potential barriers and their location, plus any information relating to their significance in terms of impact on disabled students using the resource. Prioritisation of work required to repair the resource helps make the job of optimising accessibility more manageable,
and clearly high-priority barriers in high-profile locations – such as a web site’s home page – are more likely to be encountered. The WCAG are presented in three priority groups, dependent on impact, and this can help in the prioritisation of repair work.

Next page