Accessible means that anyone, no matter their needs, are able to fully experience your learning.
For instance – if a partially sighted person were to use your course – they should get as complete an experience as a fully sighted person.
Making your e-learning accessible is essential. Law in fact:
“In the case of disability, employers and service providers are under a duty to make reasonable adjustments to their workplaces to overcome barriers experienced by disabled people”
(Called Section 508 in the US)
This doesn’t have to be a problem for you, the content creator – in fact it should be something that is integrated into your normal processes. Here are a few simple guidelines to follow to make it easy:
11 top tips for making accessible #elearning http://t.co/Vppo7fEIUb
— Elucidat (@elucidat) March 14, 2014
It used to be common practice to make a main version of your course (often in Flash), and then an HTML version with simplified content. This is bad practice because:
In practice, there is no need. If you make good, well made HTML5 courses, there is no reason why a learner with a disability cannot experience your learning to its full extent, in their own way.
There is no good reason to use Flash these days – in practice everything that Flash can do, HTML5 can do too. And HTML5 is much more accessible, works on Mobiles & Tablets, is Search Engine Friendly, and generally faster to load.
Semantic HTML means that your HTML page is, under the hood, structured as you would write a Word document –
A main title, paragraphs of text, titles for each sub-section – well structured – easy to read in short, and in a logical order.
Imagery and style is then added later as a separate process.
Order of items is very important in HTML - titles especially. One popular screen-reading tool, JAWS, will list titles and links on the page before allowing the user to decide which bits to read.
So – make sure your document is in a logical order, and that your titles and links make sense out of context (i.e. Click here will be summarised as ‘here’).
A good article for more depth: http://ruthsarian.wordpress.com/2004/12/02/web-of-information-well-structured-html/
Click / Look / See – all assume that a learner is able to do just that.
This is good practice in general – everyone reads much slower off screen than off paper. With more people using Mobile phones to experience your learning this is exacerbated. Shorten your sentences, be direct, and keep to one or two key ideas per page.
If you are using imagery in your course – think about why you are doing it - what are you communicating by putting the image there? What does the image add to the learner’s understanding?
This needs to be communicated in another way too, for people who are partially sighted. Add an explanation of the image and what it communicates to the ‘alt’ tag of the image, or make sure that the point is covered fully in the text.
We like a good Drag & Drop as much as the next person. But - if you think about it, to succeed you need good Motor/mouse skills, and full sight to be able to find the right part of the screen.
Are there other types of interaction that would get your point across just as well?
For a partially sighted person – a responsive or adaptive website is even more important than it is for you. On Mobile phones, everyone needs larger text, less imagery and shorter sentences. Find out more about Responsive Design for learning here.
You shouldn’t assume anything about how people will use your course. Try the tools yourself! Download JAWS and give your course a go: http://www.freedomscientific.com/products/fs/jaws-product-page.asp
I can’t stress this point enough – you can tick all of the boxes above, but just as you would test your learning with real learners – get as many people who have disabilities to test your course as you can.
A recent Elucidat course was massively improved by moving a text introduction from below (after in HTML) a video to above (before) it – something we never would have considered without real people testing our work.
There are brilliant choices out there that take all of the pain out making and delivering accessible HTML5. Make sure you press your vendor on accessibility, and get case studies if possible.
Equality Act 2010: