Most software will only get you part of the way there. Making an experience compliant takes effort to figure out:
The features available
The needs of the audience
How to bend the features available to the needs of the audience
Every tool on the market offers special strengths and drawbacks. Section 508 is a tidy list of requirements. But this alone won't make for a good and accessible experience
Storyline offers good support for section 508 compliance but isn't without drawbacks. Here are a few barriers you'll run into out of the box:
- Closed captioning support. This is limited to captions you create. This limitation is surmountable and can be made compliant AND a good experience:)
- Tab order. This is one of the bigger complaints. Tab order runs top to bottom (top first) and left to right (left first if 2 items are at the same Y position.) You can work around this by providing off screen elements at the top of the slide to place navigation first.
- Scroll boxes. These are not accessible unless I missed something in an update.
The workarounds in Storyline reinforce the point that there is no magic "make me accessible" button in any tool (yet:)). Other tools offer similar drawbacks and workarounds.
One other consideration is the concept of information versus training. Information doesn't equal knowledge. Knowledge doesn't equal skills. Section 508 focuses on accessibility to information. I advocate for 100% accessibility to information. However, when we talk about training, we've got to consider task authenticity in training contexts. For example, if a job that we're training folks for requires vision for safety or performance reasons, it doesn't make sense (and might actually detract from the effectiveness of the training) to have hover labels or alt tags on parts of an image. This doesn't mean leave folks with vision impairments in the dark. It just means we have to be true to the intent of the design of the solution. The compromise in this situation would be to make all of the information 100% accessible and to let the user know that an activity replicates the work and requires vision, providing an alternate path around the activity for those with impairments. As effective as we can make it for all users.
Ha! Long and rambling answer with no clear conclusion. Here's the punch line:
As far as I have found there is no one perfect tool for developing training experiences for section 508 compliance. It really depends on the types of things you're going to be doing. In some cases, Windows Notepad will be a great tool. In others, simply using YouTube and YT's subtitling tools could get the job done. Others, you'll need a number of tools to create the best experience. That said, simple is usually better for accessibility. Meaning, markup is pretty universally readable. Packaged multimedia adds a layer that makes it harder for assistive technologies to decipher.
Steve, in Articulate's comparison matrix for Flash vs. HTML5 vs. Mobile Player (here), it shows that Section 508 compliance is not supported for HTML5 output but it is for Flash. What are the differences in terms of support? I posted here re: this question, as well.
There isn't any support for visual or motor impairment in HTML5 outputs. Lots of issues ranging from screen reader to keyboard controls. Should be able to use keyboard shortcuts in a trigger.
5 Replies
Hi Kartik,
I could definitely recommend Articulate Storyline here. We're building some 508 compliant courses with it right now.
Of course there are other optins like Captivate, but we stick with storyline in such cases.
Best
Axel
Most software will only get you part of the way there. Making an experience compliant takes effort to figure out:
Every tool on the market offers special strengths and drawbacks. Section 508 is a tidy list of requirements. But this alone won't make for a good and accessible experience
Storyline offers good support for section 508 compliance but isn't without drawbacks. Here are a few barriers you'll run into out of the box:
- Closed captioning support. This is limited to captions you create. This limitation is surmountable and can be made compliant AND a good experience:)
- Tab order. This is one of the bigger complaints. Tab order runs top to bottom (top first) and left to right (left first if 2 items are at the same Y position.) You can work around this by providing off screen elements at the top of the slide to place navigation first.
- Scroll boxes. These are not accessible unless I missed something in an update.
The workarounds in Storyline reinforce the point that there is no magic "make me accessible" button in any tool (yet:)). Other tools offer similar drawbacks and workarounds.
One other consideration is the concept of information versus training. Information doesn't equal knowledge. Knowledge doesn't equal skills. Section 508 focuses on accessibility to information. I advocate for 100% accessibility to information. However, when we talk about training, we've got to consider task authenticity in training contexts. For example, if a job that we're training folks for requires vision for safety or performance reasons, it doesn't make sense (and might actually detract from the effectiveness of the training) to have hover labels or alt tags on parts of an image. This doesn't mean leave folks with vision impairments in the dark. It just means we have to be true to the intent of the design of the solution. The compromise in this situation would be to make all of the information 100% accessible and to let the user know that an activity replicates the work and requires vision, providing an alternate path around the activity for those with impairments. As effective as we can make it for all users.
Ha! Long and rambling answer with no clear conclusion. Here's the punch line:
Steve, in Articulate's comparison matrix for Flash vs. HTML5 vs. Mobile Player (here), it shows that Section 508 compliance is not supported for HTML5 output but it is for Flash. What are the differences in terms of support? I posted here re: this question, as well.
There isn't any support for visual or motor impairment in HTML5 outputs. Lots of issues ranging from screen reader to keyboard controls. Should be able to use keyboard shortcuts in a trigger.
This discussion is closed. You can start a new discussion or contact Articulate Support.