It’s an increasingly common dilemma: an organization has elected to use one or more leading authoring tools that promise accessible and responsive eLearning products published in HTML, but complaints from participants about inaccessible content and poor scalability on mobile phones continue to pour in.
Unfortunately, publishing a course with the right settings in an authoring tool doesn’t necessarily mean that it’s automatically and fully accessible. For instance, a screen reader might read all the information (which meets accessibility requirements), but not in the correct order (which is not a meaningful learning experience for people using a screen reader, since the information isn’t accessible in the same way it is to others).
How can you ensure that the eLearning courses you design, develop, or purchase are indeed accessible and responsive? Don’t assume: test them, and test them well.
What is accessible and responsive eLearning?
The globally recognized Web Content Accessibility Guidelines (WCAG) outline four principles for accessible and responsive online content, which includes eLearning: information should be Perceivable (everyone can “see” it); Operable (everyone can navigate through it); Understandable (everyone can, well, understand it); and Robust (everyone can access information from the web, tablets, laptops, desktops, mobile devices, and wearables, and different assistive technologies can interpret the information correctly).
Of course, the best way to ensure that your eLearning courses meet these POUR criteria is to start writing, designing, and developing with accessibility in mind. There are many excellent resources on how to create accessible courses available for designers and developers, including Creating Accessible eLearning: Practitioner Perspectives and tips on how to "Improve UX with Accessible, Inclusive eLearning Design."
Test with screen readers, magnification, and alternative navigation on multiple devices
Testing for accessibility involves using common assistive technologies (i.e., screen readers, magnification, and alternative navigation) and different devices (i.e., mobile, tablets, and desktops) to review every component of an eLearning course to ensure that all content is accessible and meaningful.
According to Include Everyone, Keep Everyone, a most excellent guide to web accessibility:
- The most popular screen readers are JAWS, NVDA, VoiceOver, TalkBack, and Narrator
- The easiest ways to magnify content are with high contrast tools, ZoomText Magnifier/Reader, iOS Zoom, Android Zoom, and browser Zoom
- The most prevalent alt navigation aids are voice recognition software like Dragon NaturallySpeaking, Apple Switch Control and Android Switch Access mode, Braille displays, keyboard tabs, on-screen keyboards, or a head mouse
A 5 step process
Testing eLearning courses to ensure they are accessible and responsive is not difficult, and can be completed in these 5 steps.
- Designate someone on your team to put themselves in the shoes (or chair) of learners who need or choose to access online information in different ways
- Navigate through all elements of the eLearning, including on-screen content, images, interactions, videos, and PDFs at least three times: once with a screen reader; once with a high-contrast tool and zoom magnifier; and once with a keyboard only
- Use both an accessibility checker like the SiteImprove Accessibility Checker Chrome extension and a color-contrast checker like Color Oracle to identify any inaccessible content
- Review the eLearning on as many devices as you have available to you, including mobile, tablet, and laptop at a minimum
- Most importantly, resolve all issues identified before making the eLearning available to participants
Remove common barriers to accessible and responsive eLearning
Accessibility “fails” (to use accessibility checker terminology) result in frustration for people who may have a temporary or permanent hearing, vision, physical or cognitive impairment, and include:
- Missing or unhelpful alt tags that don’t provide accurate or meaningful descriptions
- Images with text in them, like screenshots of interfaces for software training that cannot be read by screen readers
- Content that only appears in audio format, with no closed captions or text transcript
- Insufficient color contrast and font size, including in graphics and buttons
- No meaningful page titles or headings
- Inconsistent information placement (screen readers then do not pick up all of the content)
- Content that cannot be navigated by keyboard tabbing, including drag-and-drops
- Links that say “Click here” or include a web address (which might seem odd if you’re using a screen reader)
- An almost universal tendency to design complicated, nebulous interactions (tabs within a carousel, drag and drops within those carousels, or carousels in the drag and drops)
- Autoplay on videos and audio, which drowns out screen readers
Content that is not Understandable
- Repeated content like headers and footers or missing skip-to links (screen readers then read each header and footer each time it appears)
- Too many acronyms
- Missing labels and instructions for buttons or controls
- Text that does not make sense to a screen reader, e.g., “Select the best option(s), which is read as “option–parenthesis–s–parenthesis” rather than “Select the best option or options”
- Tables that aren’t labelled properly, or no well-defined header row (screen readers rattle off table cells if they are not labelled well)
Information that is not Robust
- Content cannot be displayed on mobile devices (information that appears together on a computer won’t necessarily appear together on a phone, which makes it frustrating if participants need to see information together, e.g., to make comparisons or read about an image)
- Decorative images that result in too much clicking or scrolling to get to key content on a mobile device
- Content is because it does not scale properly on mobile devices (if participants need knitting needles for fingers to be able to hit the Next button, they will become frustrated very quickly indeed)
Commit to creating and providing eLearning for all, not just some participants
Yes, testing for accessibility takes a bit of extra time, but participants will abandon your eLearning if they cannot see, hear, understand, or use all of the information you’ve spent so much time curating, designing—and paying for.
The A11Y Project, an open-source community of developers, has created a most useful checklist for meeting WCAG criteria for testing accessible online content. I encourage you to check it out and make it, along with Include Everyone, Keep Everyone, required job aids for all eLearning managers, designers, and developers in your organization.
In the words of Billy Gregory, a Canadian accessibility expert,
“When user experience doesn’t consider all users’ experience, it should be called Some Users’ Experience. Yes, SUX.”