tutorial on 508 compliance?

Jun 22, 2012

I would love (love!) to see a tutorial on how to use the 508 features in the new Storyline software. All the video tutorials you folks post are really helpful and since Storyline is said to be 508 compliant, you would be doing some of us a big favor if you showed us how to use it in making 508-compliant e-learning courses, from interactivity, accessibility tags, quizzes, etc.

This is a really important topic for those of us who provide e-learning to federal agencies or would like to do so. I think the trend will be for other agencies, state, private, etc, to move toward accessibility for users in the future.

I don't agree with the regulations, i.e., everybody has to be able to use all training materials even if they would be unable to perform the job for which the training is provided. But I, and others, have to live with them.

Tutorials would be a huge, huge help. (Did I state that strongly enough?)   

62 Replies
Steve Flowers

Great idea, Jon -

I work for the government. We take a relatively sensible approach to accessibility. It's about respect and not leaving anyone out in the cold if we can help it. The most common assumption about accessibility is that it's about making sure those with sight or hearing impairments are accommodated. This is a really narrow focus - common but not quite accurate. Accessibility is about so much more than that. From learning disabilities (quite common) to a range of devices universal accessibility is a good thing for everyone. 

We have another level of accessibility in addition to universal called authentic access. This means that if an activity is critical for practice to acquire a skill and requires an ability, don't short circuit the activity. However, don't leave folks with a disability or device that can't see it in the cold. Lett'em know what the activity requires. The law supports this, as the federal requirement upon which it was built was never intended to change the nature of the service. Just to give everyone as fair a shot as possible

On the plus side, most of these requirements also improve the experience for everyone.

Jon DeMartino

Thanks, Steve. I guess we'll just have to agree to disagree on the how "sensible" the approach is. This isn't the forum to discuss it but I'll explain what I meant and then drop it.
Let's say I'm creating e-learning training for a specific task which requires good eyesight and excellent hand-eye coordination. I can see making the training accessible for those with certain disabilities, such as deafness, epilepsy triggered by bright lights, etc., but not for those with blindness or low-vision or for those with physical impairments which would render a person unable to ever perform the task for which the training is being provided. If the guidelines were written so that accessibility requirements were related to job requirements, I'd agree. It's easy to make a blanket rule...everything must be accessible to everyone...but to have to follow this in all instances takes more time and therefore costs more money, when no one with those disabilities will ever be able to perform the task in the real world. This imposes an unnecessary burden on those offering e-learning and those who create it.  Drawing the guidelines with a finer focus would be beneficial, in my opinion.

and...I'm off my soapbox.

Anyway, I do hope Jeanettte or Tom or one of the other Articulate gurus takes up the baton and offers us some tutorials on using Storyline to create accessible training.

Sue Tedford


I'm glad you made this request!  I have high hopes that Storyline published content is accessible by all.  I love the Articulate products, but never could purchase because most of the e-learning content I've created had to be accessible.  Hopefully one of the Articulate folks can provide a tutorial and/or provide some sample projects that are accessible.


Brian Batt

Hi everyone,

Storyline’s Flash-based output is 508 compliant.  However, content published for HTML5 and the Articulate Mobile Player is not.  Please review the following article for more information:


You can also include alt text that will be read by the screen reading software:


Although Storyline content is 508 compliant, you can take your content a step farther by adding on-demand Closed Captioning by using layers and triggers:


If you really want to understand accessibility, my advice is to install JAWS and take the content for a test drive:


Once you get a feel for how a person will actually use the content in a screen reader or JAWS environment, you'll be able to develop better courses.

Jon DeMartino

Yep. I like Jeanette's expanation of the alt text, but it doesn't tell me if my text boxes will be automatically read by a screen-reader. I'd really like to see a full set of tutorials on 508 with Articlulate Storyline. I suspect that those of us who moved into training areas from healthcare or public health careers were thrust into the e-learning arena without benefit of formal training. These agencies, which receive Federal or state funding, many times require trainings to be 508 compliant so we are learning not only how to translate information, either from our own knowledge base or from SMEs, into e-learning courses but also how to make these courses compliant. I will be able to purchase Storyline if I can say for sure I'll be able to make compliant courses with it.    At this point, I'm not certain enough to guarantee that I can.

How about it, Jeanette? I think your explanations are great and would love to see a set of tutorials on this.

Steve Flowers

Here are a couple of postings that discuss the pros and cons of Storyline's 508 compliance.



There are a couple of minor annoyances with the screen reader and some organization's compliance checklists may have a problem with these items. The output is usable and most of the cons on Dianne's list can be worked around.

One thing to note, as I alluded to above with our 2 classifications of accessibility, is that perfect compliance isn't attainable - compliance is a balance. The rules are intentionally open to some level of interpretation and the ultimate test is 1) whether or not the target user can actually use the solution and 2) whether it was actually worth it.

A published output can completely meet each compliance requirement and still be completely unusable (inconveniently frustrating to the point of giving up) or useless (compromised to the point that a document would be just as effective).

Test it to see how it will work for your target population. This is also an early version of the tool, so if you find something that really doesn't work that well for your audience, report the issue so the folks at Articulate can take a look. 


Here's some verbiage from our internal operating procedures that explains what I mean by sensible accessibility rules. Sadly, very few folks actually read what the requirements say, very few take the rules all the way back to the root of law, and fewer still apply good sense to design decision-making. The rules aren't intended to circumvent good design as draconian law, merely to provide some semblance of autonomy and fairness for those that don't have the same physical advantage as the majority. This stuff doesn't need to be a difficult battle.

"Government agencies providing services and information through any channel are 

obligated to provide universal access to all citizens and employees. Policy, checklists, 

and guidelines exist at the agency level and shall be followed. This section defines a 

model for practice that provides usability while considering the task being trained.

Universally Accessible - Provides a positive experience and complete access to information

regardless of the physical abilities of the user. 

Principles of universal access apply to all ADL products. Much of the discussion 

surrounding accessibility is focused on narrow cases. This relegates Section 508 

compliance testing to “works in a screen reader” or “is closed captioned”. While these 

features are important, this narrow focus ignores a larger audience with disabilities that 

include color blindness, partial vision, motor control and learning disabilities. This 

focus can also lead to unnecessary compromises in the design of the experience.

42 U.S.C. § 12182(b)(2)(A)(iii)

(iii) a failure to take such steps as may be necessary to ensure that no individual with a 

disability is excluded, denied services, segregated or otherwise treated differently than other 

individuals because of the absence of auxiliary aids and services, unless the entity can 

demonstrate that taking such steps would fundamentally alter the nature of the good, 

service, facility, privilege, advantage, or accommodation being offered or would 

result in an undue burden;

The law indicates that a person with a disability cannot be excluded or treated 

differently than a person without the disability. The law also implies that fundamentally 

altering the nature of the service being offered is considered unacceptable. While we 

must pursue universal accessibility at each opportunity, we must also consider the task

represented in the training product. 

If the task requires abilities to perform a task, we must authentically represent these 

tasks in practice. In other words, making design compromises that alter the authenticity 

of the performance of a task defeats the purpose of the training tool. In such cases, 

partial compliance or exclusion from compliance is reasonable; but only for the 

activities that represent the task. All other elements of the product will be universally 


This model of accessibility is sensible and considerate. The key to providing a 

sensible level of support for universal accessibility is in determining the performance 

requirements for the task being trained. For example, if a task requires sight or hearing

to perform, this activity will not, necessarily, provide an authentically accessible 

alternative. However, the solution will let the disabled user know that the specific task 

and associated activity require these abilities. The solution will also provide the 

opportunity to skip the activity. This is the considerate component of the model. This 

provides a best of both worlds experience for all users without making inauthentic 

compromises or confusing impaired users. This model for construction provides a clear 

set of principles that make products work for everyone, every time and should eliminate 

waiver requests.  This does not provide an excuse to make technology choices that make 

accessibility difficult. Nor does it provide permission for developers to avoid 

accessibility all together."

Jon DeMartino

"The key to providing a sensible level of support for universal accessibility is in determining the performance

requirements for the task being trained. For example, if a task requires sight or hearing to perform, this activity will not, necessarily, provide an authentically accessible alternative. However, the solution will let the disabled user know that the specific task and associated activity require these abilities. The solution will also provide the opportunity to skip the activity."

Thanks for taking the time to explain the intent of the law, Steve. And I'm sure you're correct about people not taking the time to research the root and intention of the regulations. Maybe you can explain just a bit further to nail down a solution for me. Let's say I am creating an e-course which represents a virtual  Iaboratory, where the user will select tests, view colony growth and see images taken through a microscope to help determine the identity of a bacteria. While it may be true that a person with low vision could see with a properly adjusted microscope, there is much more to the entire task than this and such a disabled person could not perform this work. If the entire course is limited to this one task, i.e., identifying a bacteria ......or performing any other laboratory task for that matter, how would I provide the 'solution' you mention, of letting the disabled user know that certain abilities will be required for the specific task and also how do I 'provide the opportunity to skip the activity'? I can't see how or why such a person would  be accessing this course in the first place. Do I have to post a statement that notifies everyone who might find their way to the site, in a compliant manner, that this is the case?

It almost sounds like you're saying the law is intended to do what I originally mentioned, so that if a user would be unable to perform the task for which training is being provided, that training does not need to be accesible for those disabilities which would render the user unable to perform the task.

I appreciate any further clarification you can provide.


Jon DeMartino

I've been working on 508 compliance in a Captivate program and find there is a problem using the Tab key on the keyboard because when the next slide appears, the tab is at the bottom and the screen reader starts reading at the bottom of the page instead of at the top left, as would be expected. Can someone familiar with Storyline tell me if navigating from screen to screen using Tab causes the same problem?


Jon DeMartino

I'm working on a sample for 508 compliance and have a question about how the tabs work. In the published file uploaded below, is there a way to make the tabs keep moving forward and down to the navigation buttons after the user selects a response and reads the feedback without continuing to go back up to the top? I have made some of the content invisible to the reader, thanks to one of Jeannette's tutorials but is there a way to make something invisible the second time through? I would think the navigation on this slide would be confusing.

Steve Flowers

Hi, Jon -

That's a tough one. I think the order resets when a new object is shown and the tab order around the edge is a little goofy and unpredictable. One way to help is to build some keyboard navigation into your slide master using key triggers (Jump to slide > next slide > When user presses a key > Right). That way there's a convenient way for the user (including fully physically capable folks) to use convenient navigation using the keyboard.

The other way you might be able to get around this is by putting next / back navigation off the stage to the right of your interaction. Since tab order goes left to right from top to bottom you can leverage the mechanic by placing navigation elements specifically for use by keyboard tabbers off of the slide. By adding this to your slide master it could minimize pain of adding these to every slide.

Using this same mechanic you could skip over repeat links by adding slide level buttons at the top of the slide, just out of view.

Hope this helps,


Jon DeMartino

Thanks a lot, Steve. I set the right and left arrows as navigational tools on the keyboard, on the master slide view. This works really well. I just have to let the user know this on the first slide.

Now I have a new wrinkle. I'll attach a snip of the problem. It's a question slide with two choices. The second choice is located right next to the first so I would have thought the tab cursor would go there next but it goes back up to the top of the screen and reads the instructions again, then back to the first choice and finally to the second choice. I don't see a way to hide the instructions after it reads them once. Maybe i need another layer with the second choice only and no instructions. I'm starting to confuse myself now.

Jon DeMartino

Here's another problem I'm finding. When the correct/incorrect feedback appears and I use the tab keyboard key to navigate around the slide, the yellow highlight (indicating this will be seen by the screenreader) goes to the entire feedback box, then the first line of writing, then the straight line that is part of the feedback box, then any text below the line. I can make any of the text invisible to the reader but is there a way to not have it pick up the line that's part of the feedback box? It is not separate and I can't make it invisible as far as  can tell


Jon DeMartino

Thanks, Jeanette! That worked great. I was also able to make the feedback "box" invisible to a screen reader so the tab key will skip right over the shape and the reader will read just the feedback text and the "continue" button.

Now, next question...and this may be something basic that I missed. There is no sound when the user clicks the continue button on the feedback screen or the "next' button on any slide. I'm not sure how the unsighted person will know they have actually clicked a button and that they should use the tab key again to "read" the feedback. Is there an option to add mouse or keyboard sounds?  Maybe I have something turned off that I need to toggle back on.


Jeanette Brooks

Hi Paul - if you have audio narration at the beginning of each slide and/or feedback layer, that could be sufficient to signal to a non-sighted learner that a new slide has started. If not, you could always go into your Slide Master view and insert a very short sound effect at the beginning of the slide master  timeline, as a visual cue to the learner that the slide has transitioned. You could do the same on the Feedback Masters, as these are used for the feedback layers that display after the learners submit an answer to a question.

Jon DeMartino

I'm still wrestling with 508 and trying to make notes and pull together a list of things I can do to satisfy state and federal clients. However, it would be much better to have a tutorial on how to use all the available options in Storyline to make a compliant course...even  just the basics of 508 would be a place to start.

Jeanette, how about it? Your tutorials are always well thought-out, logical and easy to follow.

With funding issues at all levels, many state and federal agencies will probably be turning to internal staff or freelancers to create cost-effective e-learning courses....but they will have to be 508 compliant. Your staff would not only be helping all of us in this 508 boat, but probably expanding your customer base as well.

If anyone else has a tutorial or even a document listing the applications and steps to take to make such a course, please let us know. Meanwhile, I'll keep hoping that Jeanette or one of the other gurus comes through for us.



Laura Davies

Jeanette, any idea how long we need to wait for a tutorial for 508?  We have a course coming soon to a deadline. SOON.

I've asked for help with a support case that hasn't gotten us any closer to a working screen reader version, I've posted on the community looking for a "best practices" and not gotten a response (except from someone else who also needed help).


We've covered the closed captioning. We've covered the color-blind contrast issues. We need to know the best practices for working with a screen reader. Because our main training course has a fair bit of animation/movement, and many of the slides in a scene advance automatically, we're thinking the screen reader version has to be a separate course.  For Storyline to keep working for us, we'll need to either design future courses differently so everything can be one course, or learn a better way to use this software.

Here's what I'm assuming based on what we've been able to discover so far:

  • User would use 'tab' to move through the screen (left to right, top to bottom) with the text or images highlighted with the yellow box
  • I understand how to add "alt text" as needed for images, along with choosing if each item on the slide is visible or not to the screen reader
  • All slides should be advance by user
  • All slides should not have audio that starts automatically, or have just a sound to show that it's a new slide
  • All images/phrases/words on screen should be initially visible (meaning no animation in or out) so they don't get skipped by a screen reader

Am I incorrect on any of this?

Where would you give the user instructions on navigating the course?

What else have you found that we're still missing?

Thanks all.

Jeanette Brooks

Hey Laura, I'm sorry, we don't have a date pegged for the upcoming resources, but rest assured that we're eager to make them available once we're confident they're solid. I think you've got a lot of good guidelines in the bullets you listed. To a great degree, often the accessibilty guidelines on a given project are driven by client-specific requirements which might or might not apply to all courses in every case (one of the reasons why this topic can sometimes be difficult to nail down). In addition to the guidelines you mentioned, one practice that I've also seen that can help with regard to slide advance is to set up hot keys that allow the learner to advance with just a keystroke rather than having to tab  to the Next button every time. Regarding the support case you mentioned: if you haven't gotten resolution on Storyline's behavior with a screen reader, would you mind replying to the support engineer so that the support team could reopen your case and continue to help troubleshoot?

Jon DeMartino

One thing I tried is to make a note that is invisible to all but those with a screen reader, to provide them with the information that is on the slide, but which will be inaccessible to them. In this case it was a drag-and-drop slide. I made a small box about the same color as the background so most people wouldn't notice it near the top of the slide. I made it visible to the screen reader and added alt-text that provided the information shown on the slide, i.e., "On this slide, items were dragged to the correct receptacle, based on the type of item. The used gloves belong in the biohazard waste, paper in the recycle bin and  cleaning materials were placed in the closet. Please use the right arrow on the keyboard to go to the next slide. " 

I then made all the items on the slide invisible to the screen reader except for this explanatory alt-text item.

I think this could also work for an Engage slide, if these can be used in Storyline. If so, I'd just place a similar box on the previous slide with alt text to give them the same information as is available to mouse-users on the next slide and then ask them to click a button to skip that next slide.

I think this might be a way around slides like drag and drop and others that screen-reader users can't do.