Following on from my post One Person’s Strategy is Another’s Barrier, where I talked about using complementary approaches to e-learning resource accessibility, Becta’s Making Software Accessible: A Guide for Schools (PDF format, 468Kb) helpfully provides a summary of the legal requirements in the UK (United Kingdom) surrounding the provision of e-learning resources. One of the points states that:
“…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…?
Sharon – you’re right that the lack of definition leaves flexability for those who feel informed, supported and able to make decision about what is or isn’t accessible, what is an alternative and whether or not the provision is equitable, unfortunately though most content providers and many (if not most) practitioners aren’t fortunate enough to be in that position so some pointers as to technical conformance is very useful. One of the things we aim to do in “making accessible software, a guide for content providers”, the sister publication to “making software accessible, a guide for Schools” is point to the Standards specs and guidelines which are applicable to environments other than the Web. Working on the premise that that which is documented / standardised is more ‘reasonable’ than that which is not. By following the URL given in the back of the publication
www.Becta.org.uk/industry/content/accessibility
you can see a list of essential and desirable access requirements for all digital learning resources and links to guidance on implementing these in a range of development environments. It is reasonable to expect a content provider to implement a given function if you can point to guidance on how to do so. It may not be reasonable if a methodology can’t be identified.Hi Adrian
Thanks for the link to the resources – there’s a lot of useful information there.
I agree that guidelines and specifications are necessary to inform and aid technical development, but content developers also need to think “out of the box” when those guidelines don’t help to provide the solutions required. However, this holisitic approach should complement the foundation of technical guidelines and standards.