“…use of an ICT [Information Communication Technology] with an accessibility barrier is not necessarily unlawful under the DDA [Disability Discrimination Act], so long as:
* Existence of the barrier is justifiable on academic, technical or financial grounds; and
* The educational organisation using the ICT provides equivalent alternatives to allow affected disabled people to reach the same learning objective as provided by the inaccessible ICT.

Where a barrier exists and can be justified on the grounds specified… above, information about the justification should be provided by the ICT producer and used by the educational organisation to inform provision of suitable alternatives.” (Becta (2007). Making Software Accessible: A Guide for Schools. Accessed 12/09/07.)

Perhaps it would be helpful if all resources were marked with metadata which described what a learning resource consisted of.  So for example, a Flash animation with captions could be identified as having audio, visuals, and captions.  This would help learning technologists and learning resource providers to provide alternatives to students.  The IMS AccessForAll Meta-data Specification provides a way of marking up e-learning resources with metadata which describes their modality – e.g. “hasText”, “hasAudio” etc.  A simpler format has also been developed by TechDis – the Accessibility Passport.  This idea allows content creators, tutors, and students to describe the accessibility of a resource in the form of a passport which travels with the resource (perhaps in the form of an online web page).  For example, a content creator describing a Flash animation could state that it is in English, with audio, visual and captions.  A student might then comment to say that there is a time lag between the animation and the captions or a tutor could leave a comment to say that it had been translated into German and its location.  Another content developer might comment that an alternative resource for the same learning objective had been developed for visually impaired people.  (Obviously, I’m not going into IPR (Intellectual Property Rights) here or the actual technical logistics, but hopefully you get the idea!)  It would also help to “inform provision of suitable alternatives” as mentioned above.

However, provision of alternative resources must still be accessible by students or further alternatives provided – as mentioned in my last post: one person’s strategy may be another’s barrier.

One of the issues with UK accessibilty legislation is that there is no technical definition of what constitutes an accessible e-learning resource or a “reasonable adjustment” as described in SENDA (Special Educational Needs and Disability Act, 2001).  Guidelines such as those developed by W3C WAI (World Wide Web Consortium Web Accessibility Initiative) have been accepted as de facto standards but they are not designed for e-learning and the UK government has not stipulated that they must be used.  Most developers do so voluntarily.  One of the main disadvantages is with the lack of technical definition is that developers can often feel as though they are “feeling their way” with accessibility.  On the other hand, there are distinct advantages.  By not defining a technical definition of what constitutes accessibility, developers are given free rein to produce solutions which, whilst perhaps not strictly conformant to the various guidelines, are actually accessible.  Also, innovation is allowed to flourish – such as in the form of the new Web 2.0 technologies – and give rise to new ways of working and approaching accessibility and learning.  Again it is the one size fits all versus holistic approach, but rather than seeing them as conflicting approaches, they should be considered as complementary.

So what approach needs to be taken to ensure that one is legally compliant?  The answer is easy: work alongside current guidelines and provide equivalent alternative resources, where necessary.  In other words, do as much of the generic accessibility as you can (such as making sure your HTML (HyperText Markup Language) validates) and provide alternatives as necessary, where this isn’t possible (e.g. provide a transcript of a podcasted lecture for students with auditory impairments or without access to speakers).  Straightforward in theory, but in practice…?