Considerations in Developing Accessible Courseware
- No Comments
Currently, the official standards for Accessibility compliance in the US are found at ADA.gov, covering the entire Americans with Disabilities Act. The site itself is a trove of information for those who really want to explore and understand the large range of requirements, from IT to public accommodations.
Fortunately for those of us in eLearning, a secondary government website has been created to focus on the IT aspect of the overall ADA – Section508.gov. Among the large bits of information available are a ‘Summary of Section 508 Standards’ and a few ‘Technical Guidance’ documents. Other government sites provide even more detailed information, such as the Department of Veteran’s Affairs….which is especially welcome since each federal government agency seems to have its own subset of what it considers required and optional 508 compliance.
So that’s the first consideration; regardless of the customer – whether federal or state agency, or an association or non-profit, or a company from another country – they may well have their own version of the Accessibility requirements. For example, the DOD, EPA, and Department of Health and Human Services, or Canada’s Standards on Web Accessibility versus Ontario’s specific AODA. You definitely want to be sure to target the agency’s specific 508 requirements so you can deliver to their specific requirements.
Most authoring tools offer some form of Accessibility features in the published output, though the tools are generally not ‘Accessible’ themselves.
Adobe Flash, while falling out of favor quickly due to lack of wide mobile support, had made significant improvements to its Accessibility features over the years. In the earlier days of 508 requirements, conventional wisdom was to avoid Flash. However, over the past couple years and currently, you can make very friendly/accessible web applications and courses with Flash.
Articulate Storyline has decent Accessibility features as well, though some are quirky and it lacks (of this writing) an included Closed-Captioning feature. While a custom CC function can be created using creative layers and triggers, it is far from ideal. Storyline, while a great overall product, also has an issue where a screen reader will state the actual name of an embedded variable, not the variable’s value…which we’re sure will be fixed shortly.
Adobe Captivate is a bit more mature in its Accessibility feature set, including a solid Closed-Captioning function. Being a bit further along, we’ll cover some simple steps to enable this feature in a Captivate 7 project. Checking the “Enable Accessibility” option in the Preferences > Publish Settings dialog enables these elements:
- Project name
- Project description
- Standard and Question slides
- Slide labels
- Button labels
- Playback controls/functions
- Tab Order
One of the most complex components to setup for Accessibility, regardless of the tool, is compatibility with screen-readers – such as JAWS – so they can read all elements on the screen which make sense, and skip those that do not. Here are a few tips in the context of Captivate development (though they are still generally valid regardless of the tool):
- Review your project frequently with the screen reader to ensure your narration or text-to-speech is not overlapping the screen-reader. You may want to prevent automatic playback of narration and have the user click (or touch or tab-to) a ‘Play Narration’ button so they can start it up when they’re ready.
- Test the screen text on each slide. Screen-readers are still imperfect and complex words or obscure terminology will likely not be read clearly. Keep your content more simple as opposed to more technical, as appropriate for the audience and subject matter.
- Watch for relying on color for navigational hints, and for color-blind conflicts. For navigation, use font styles in addition to colors; for color schemes, this Penn State site is a great primer and reference.
- Provide ‘alt’ text for images – be sure all images have a name (properties) that makes sense when the screen-reader encounters it.
- For all navigational and other interactive functions – things that can be clicked or touched to activate them – most every 508 specification will require a keyboard equivalent (i.e. Tabs, Return, etc.).and be sure to test those keyboard alternatives while running the published project with a screen-reader, as sometimes those readers like to intercept keypresses.
To wrap up, a final process to help setup Closed Captioning in Captivate by converting Slide Notes within the project:
- Select the check boxes in the closed captions column and corresponds to the notes you want to convert to closed captions (the check boxes are greyed out if the slide does not contain any audio.
- Select “Closed Captioning”
- To time a closed caption, click the header of the caption that displays the start and end time, and drag the playhead in the audio clip.
- Click “CC Project Settings” to change the overall CC text styles.
- Go to Project > Skin Editor and click Closed Captioning to enable display in the published project. When published, click the ‘CC’ button on the playback bar to view the closed captions.
Despite all those features and options available in most all authoring tools, one issue which still needs resolution is how to allow for optimal Accessibility on mobile devices.
- Can touch screen keyboards adequately substitute for ‘real’ keyboards?
- Do the various mobile devices come with quality screen-readers and do they work to the same level as the deeply-tested tools like JAWS?
- Is a simple reverse-pinch or responsive design enough to compensate for challenges inherent with small screens and devices?
Our ADA, Section 508 guidelines are due for a significant review and update with the quick advancement in mobile technology.