508 Compliance using Articulate Storyline

Westpac, an Australian-based client, recently asked us to take a cultural awareness training course we previously built for them and make it 508 compliant.

Section 508, an amendment to the United States Rehabilitation Act of 1973, is a federal law mandating that all electronic and information technology developed, procured and maintained be accessible to people with disabilities.

The cultural awareness training course was originally built in Articulate Storyline. While Flash-based development tools will never be fully 508 compliant, Articulate Storyline does provide support for the major rules that 508 compliance demands. It also supports major screen reader technologies, such as JAWS (Job Access With Speech), allowing me to test the output. The JAWS software provides speech and Braille output for PC users with visual disabilities.

Without going in to too much detail about the course and the 508 compliance difficulties I experienced with Articulate Storyline (nothing too serious, thankfully), the following is my account of how I dealt with the major 508 compliance rules, namely alt text and keyboard support.

• Alt Text:

The course had 86 slides and there were a lot of non-text objects on each slide. For each non-text object, you need to create an alt text description.

Articulate Storyline provides a feature to do this. Right-click the object and choose Size and Position. There is an Alt Text section in the dialog to add your text that a screen reader (JAWS) can read.

There might be some objects you do not want alt text for; an example of this would be a graphical element you are using for decoration. If you do not want that object to be readable, uncheck Object is visible to accessibility tools.

The biggest issue I found with this is that you will be dealing with an object that has multiple states a lot of the time. Simply adding the alt text to the object as outlined will not work. You also need to drill into each state of the object and add the alt text individually, or else the descriptions will not be read by the screen reader. This meant quite a bit of re-work, as you can imagine. Hopefully, this piece of information will save you time where it cost me!

• Keyboard Support:

To meet 508 compliance, the course needs to be fully accessible through a keyboard.

In order to achieve this, you need to enable keyboard shortcuts; you will need to create a trigger associated with the desired object/action.

You do not need to create keyboard shortcuts for every clickable object on the slide. By pressing the Tab key, users can navigate to the different objects on the slide (a yellow box appears around the selected object). Users can then press Enter to trigger the action on that object.

It must be noted that keyboard shortcuts do NOT work in HTML5 output.

The biggest issue I had with keyboard support is that on some of the interactive slides, pressing Enter on an object was not triggering the action. After quite a bit of time investigating the issue, I discovered it had to do with the object\’s states.

In the original course build, every clickable object was given a visited state, which involved layering a green checkmark image over the button while in that state. This meant that the states were different, or not balanced across all objects.

For example, a button will have a Normal state. It might also have a Hover state, which is the same button but with different formatting applied. The Visited state contained the button object plus an image object layered on top, which corrupted the button. While this had no impact on clicking the button, for keyboard support, it prevented the trigger from firing when the user pressed Enter on the object. I have no explanation as to why this is the case. What I do know is that on removing the checkmark object from the Visited state, the trigger worked correctly.

Once again, this meant a lot of re-work on my end to go through every clickable object and balance the states. Also, I needed to keep the functionality of showing the checkmarks once an object had been visited. I did this by creating separate layers for each checkmark and revealing them once an object had been clicked.

 

For future developments, I have created a checklist to account for these issues. It is a lot easier to build to 508 compliance standards than it is to re-work something that has already been built.

I hope the pain I suffered will save you time when making your courseware 508 compliant in Articulate Storyline! If you would like a copy of my 508 compliance checklist, please just drop me an email.

 Shane McCarthy, Lead Media Developer, PulseLearning Development Team

Email: shane.mccarthy@pulselearning.com