It’s an increasingly common dilemma: a company has chosen to use one or more authoring tools that guarantee responsive and accessible eLearning products but complaints from participants about inaccessible content and poor scalability on mobile phones are still pouring in.
Regrettably, publishing a path does not necessarily mean that it is automatically and reachable. For instance, a screen reader might read all of the information (which meets accessibility requirements), but not in the right sequence (which isn’t a meaningful learning experience for people using a screen reader, because the information is not accessible in the same way it is to others).
How do you ensure that the eLearning courses you develop a design, or buy are responsive and accessible? Do not presume: test them, and test them.
What’s eLearning that is responsive and accessible?
The globally recognized Internet Content Accessibility Guidelines (WCAG) outline four principles for responsive and accessible online content, which includes eLearning: advice 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 internet, tablet computers, notebooks, laptops, mobile devices, and wearables, and distinct assistive technologies may interpret the data correctly).
Of course, the ideal way to ensure your courses meet these criteria is to begin growing accessibility in mind, designing, and writing. There are many excellent resources on the best way best to create accessible courses out there for developers and designers, including Building Accessible eLearning: Practitioner Perspectives and advice on ways to “Improve UX with Accessible, Inclusive eLearning Design.”
Evaluation on devices with magnification, screen readers, and alternative navigation
Testing for accessibility entails utilizing shared assistive technologies (i.e., screen readers, magnification, and alternative navigation) and distinct apparatus (i.e., mobile, tablet computers, and laptops) to review each part of an eLearning class to ensure that all content is significant and accessible.
According a most excellent guide to internet availability, to Include Everyone everybody:
The screen readers are JAWS, NVDA TalkBack, and Narrator
The ways to Publish content are with browser Zoom, ZoomText Magnifier/Reader, iOS Zoom, Android Zoom, and high-contrast tools
The most prevalent of all navigation aids are voice recognition software like a mind mouse, Apple Switch Control and Android Change Access mode, Braille screens, keyboard displays, onscreen keyboards, or Dragon NaturallySpeaking
A 5-step Procedure
Testing eLearning courses to ensure they are responsive and accessible isn’t difficult, and can be completed in these 5 steps.
Designate someone in your team to put themselves in the shoes (or chair) of students who want or choose to access online information in different ways
Navigate through all elements of this eLearning, including onscreen content, pictures, interactions, videos, and PDFs at least three occasions: once with a screen reader; after with an instrument and zoom magnifier; and after with a keyboard just
Use both a checker like Color Oracle and an entry checker like the SiteImprove Accessibility Checker Chrome extension to spot any content that is inaccessible
Review the eLearning on as many devices as You’ve Got available to you, including mobile, tablet, and notebook in a minimum
Before making the eLearning accessible to participants, resolve all problems identified
Eliminate to eLearning that is responsive and accessible
Access “fails” (to use accessibility checker terminology) cause frustration for People That may have a temporary or permanent hearing, vision, physical or cognitive impairment, and comprise:
Missing or unhelpful alt tags that don’t offer descriptions
Pictures with text in them, like screenshots of ports for applications training that Can’t be read by screen readers
Content that only seems in audio format, with text transcript or no closed captions
Inadequate color contrast and font size, including in buttons and images
No significant page titles or headings
Inconsistent data positioning (screen readers subsequently don’t pick up All the articles)
Content that Can’t be navigated by a computer programmer, including drag-and-drops
An almost universal tendency to look complex, nebulous interactions (tabs within a carousel, drag, and falls within those carousels, or carousels in the drag and drops)
On sound and videos, which drown screen readers out
Content that is not Understandable
Repeated content like headers and footers or lost skip-to hyperlinks (screen readers subsequently read every header and footer Every Time it appears)
Too many acronyms
Missing labels and instructions for switches or controls
Text That Doesn’t make sense to a screen reader, e.g., “Select the best alternative (s), which is read as”option-parenthesis-s-parenthesis” instead of”Select the best option or options”
Tables that are not labeled correctly, or no well-defined header row (screen readers turn off table cells if they Aren’t labeled well)
Information That’s Not Robust
Content Can’t Be displayed on mobile devices (data that appear together on a PC won’t necessarily appear on a phone, making it frustrating if participants Will Need to see information collectively, e.g., to make comparisons or read about an image)
Decorative images that lead to too much scrolling or clicking for to content that is key on a mobile device
Content is because it does not scale correctly on mobile devices (if participants want knitting needles for fingers to be able to reach the Next button, they will become frustrated very quickly indeed)
Commit to supplying eLearning for everybody, not just some participants, and producing
Yes, even testing for accessibility takes a bit of time, but participants may leave your eLearning whenever they can not see, hear, understand, or use the information you’ve spent so much time curating, designing — and paying for all.
For analyzing online 25, an open-source community of programmers, Even the A11Y Project, has made a checklist for meeting WCAG standards. I urge you to check it out, and make it, together with Include Everyone, Keep Everyone, demanded job aids.