508 Compliance

Hi Heather,

For each element you outlined, there is a corresponding Section 508 official guideline (as I'm sure you know!)  One thing you can do is trace each element back to the actual requirement on the official 508 website. (Again, I'm stating the obvious!)  When I did a search on the keywords "bitmap images" (from the first element in your list) on that website, and was pointed to its associated requirement, here's what I found:

(e) When bitmap images are used to identify controls, status indicators, or other programmatic elements, the meaning assigned to those images shall be consistent throughout an application's performance.

What forms of bitmap images are affected by this provision?

This provision applies to those images which are used to indicate an action.  An image used strictly for decoration is not covered by this provision.

So the requirement is essentially referring to what equates to "custom controls" in Storyline.  Instead of using one of the built-in buttons, for example, you might use a .bmp image (or .jpg or .png, etc) that has a trigger associated with it to function as a button.  Section 508 requires that you not change the action that you assigned to that specific image.  If you use a clip art arrow in place of Storyline's "Next" button, then don't use that same clip art arrow to mean or do something else, elsewhere in your project.

That was an easy one :)   I am going to look at the other elements in your list and will hopefully be able to provide you a straightforward answer on how to implement them in Storyline.  Stay tuned!

Hi again Heather,

Animation:  The easiest solution for accessibility is, don't use animation. (Section 508 1194.21(h))

Drag and Drop; Hotspots:  As stated at the top of the article you referenced, Storyline does not support keyboard alternatives to drag-and-drop and hotspot interactions.

Captions:  Storyline 360 supports closed captions for video and audio media.  Everything you need to know about creating and implementing captions can be found right here.

Text-only Course Versions:  If there is no way for you to make something accessible in your course design, then you must provide an accessible, text alternative.  Using the Notes feature, or Resources, as you mentioned, are both viable alternatives.  If for some reason those options won't work, your best bet might be to re-think your design of that element.  This is a really broad category.  I found some helpful guidelines here.

Skip repetitive links:  In Storyline, there is a Skip Navigation feature built into the player, that allows the learner to bypass all Player objects and controls, and return directly to slide content.

Open and Closed Captions:  Open captions are always in view and cannot be turned off, whereas closed captions can be turned on and off by the viewer.  See my previous answer on Captions.

Audio descriptions of contents:  This can be accomplished with the learner's use of a screenreader.  Alternatively, you could use the Record Mic feature in Storyline to record your own narration.

Hopefully you're good to go now!  

I look forward to more information on the questions addressed here. What you've provide above is awesome.

My courses use a lot of animation and narration. I was thinking I'd have to create an accessible version that removes the animation, but I wonder if a text alternative is acceptable.

Do any of you have one course with animation and captions (for deaf and hard of hearing) and another without animation and careful consideration of tab order and alt text, for example? The people in the department I create courses for would be very unhappy if something didn't move on the screen every 20 seconds or so.

Thanks! 

Something I've done with some success is to create separate slides for specific portions of courses that are complex (typically animation). From the homepage there is a toggle for the user to select whether or not they want the 508 version of the course (basically this is for screen readers), and when they get to the specific slides that have animation I have a T/F variable set up that is tied to the 508 toggle (if it's set to true they get a text only version of the slide where the animation is explained; if it's set to fault they get the full animation).

Very elegant solution, Benjamin. Thanks for weighing in. That's what I was thinking for the whole course - just to point to a different scene that's 508 compliant.  Thanks for validating my thoughts!

This is a great discussion. Could someone please comment on the use of lightboxes in SL3 and 508 compliance? I have a slide with links to 4 different lightbox pages. Once the user gets to the light box page, there are a series of hotspots. From what I'm reading, the hotspots need to be converted to buttons for 508 compliance. Is the use of lightboxes going to present problems re: compliance? I've visited the official 508 website but it doesn't explain (for the lay person) the "how to..."  

Regarding the text animations alluded to above, I'm hoping someone can further elucidate the issue for me. It sounds like the issue is that when there is animation on a text layer, the animation might interfere with a screen reader's ability to interact with it properly. Is that correct?

If so, is this still true with the latest version of Storyline 360? Even if it's just a simple animation, like a fade-in at the beginning of a timeline?

Very good to know, if so!

Animations are a little tricky. If they have audio you need to include closed captioning. Don't bury any instructional content in an animation. A visually impaired user needs to get the same instruction as non-impaired user. Technically, you're supposed to describe the content but not everyone does it. A backup option would be to include a text description for the impaired user.

Nothing should ever animate on its own. A user should always have control over an animation starting. If you have text coming onto the screen make sure you can leave it there so a user can tab to it. For example, 2 characters talking could have speech bubbles pop up over their heads. The text should stay on screen vs moving off or fading off at the end of a slide.

A couple of thing missing in this chain is 1. color contrast - your material needs to pass the color contrast ratio test. There are some good online tools for checking it. As an example, the grey color text used on this page (Reply, Quote, Flag, Mark as Helpful, Bookmark) - those fail Section 508. 2. - tabbing order needs set for every slide. If you have content objects on screen a person with a keyboard should be able to "tab" to those items. You can't rely on someone using a mouse.

Ugh... where to start... maybe I should do a screener on 508 one day. Storyline is getting better, but there are several things that still need addressed. Here's a few items I know of that are not 508 and you need to create workarounds for them:

Built-in Hotspots, Hyperlinks, Animated Markers, Feedback Box tabbing order, accessed slides color change on menu, drag-and-drop questions, etc.

Thanks for your response Bob. When you say "nothing should ever animate on its own," is that a hard and fast rule or a general guideline? For instance, would that include even super basic intro animations like fading in the text on slide opening? Is there a reason that would not be considered accessible?

I understand the risk of text animating out, on its own -- it may disappear before a user/screen reader has the opportunity to interact with it. Are there any accessibility reasons that fading a bulleted list in "by paragraph" (as Storyline allows) would not be compliant?

There seems to be a near infinite amount of nuance to getting accessiblity right, so I'm hoping to lean on some of the veterans in the community just a little. I'll do my best to document my own discoveries & strategies along the way as well.

Thanks,

ephraim

We've done some slide transitions like you mention and they were not flagged. Quick fades. Fading borders along the lines of screen flickering which is a 508 fail. So far we only had one thing we needed to change out. We used the built in animated markers for a project and got flagged for the flickering notice on those.

There's something like a 3-5-second rule for moving objects. If someone moves longer than that you need to give the user the option to stop or pause it.

We usually just give the user control to start an animation. As long as you offer the option to pause/play the content you should be ok. Funny, I checked the new rules again and all they mention is to make sure the user has the option to pause/play the content.

For fading bullets - I know we tested those in the past and the screen reader didn't pick up the entire text block. Guess it would be good to test it again on the latest version. I'll get our JAWS tester to check out fading bullets/paragraph text in 360. Now I'm curious too.

Its a moving target - what we've found is one agency goes down the list rule-by-rule while another doesn't always hit everything. The standard is there, they just don't always follow it.

Awesome information, thanks for sharing Bob. And if you do run any more tests to revalidate some of this information in the latest version, especially around bullets, please do share out the results here! I've subscribed to the thread so as not to miss it.

Thanks!