WARNING: Accessibility bug in Storyline (WCAG/508 compliance)

Nov 05, 2016

For those of you who think you have created an accessible course in Storyline, I urge you to test your published courses using a screen reader. There are two important bugs you need to be aware of as they may have caused you to breach your contractual obligations in relation to WCAG 2.0/Section 508 compliance (not to mention being extremely frustrating for your learners who rely on screen readers).

Bug #1: If you add Alt text to a button after adding a state, the Alt text doesn't work.

Bug #2: If you update Alt text on a button after adding a state, the Alt text doesn't work.

I've created a video demonstrating these bugs. Click the image below to watch it. 

Articulate Storyline WCAG 508 Accessibility Alt text not working

Articulate are aware of these bugs. While we await a bug fix, the only workaround is to do the following:

  • Ensure you add Alt text before adding states.
  • Do not attempt to duplicate a button and then update the Alt text on the subsequent buttons. Create all buttons from scratch. 
  • If you need to update the Alt text on a button at a later stage, ensure you delete the button and recreate it (and all its states and triggers) again from scratch. 

This workaround is extremely tedious and time-consuming, but at least it's better than finding out that your course is not accessibility compliant!

Please test your published courses using a screen reader (you can download a free one here) and reply to this post if these bugs have impacted on any of your work. Hopefully we can get them bumped up the bug priority list!  

83 Replies
Jaidyn Martin

Do these bugs apply only to buttons? I am using custom shapes that act as buttons (with states), will these be affected?

I've noticed a lot of bugs in general with tab order and grouped objects/object states. For instance, you can't change the visibility of grouped objects to a screen reader, you have to edit them individually. I am about to send more projects to my client's 508 testers so these sorts of things make me nervous, especially since I've made over a dozen courses all sharing the same resources and object/trigger structure.

Kuriko A

This bug applies to image buttons, not custom shapes. Having said that, I'd highly recommend using a screen reader to test your courses before sending them to your client's 508 testers. Since you haven't, I can understand why you would be very nervous! You should try the free screen reader called NVDA which I linked to in my original post. You'll have much more peace of mind if you can quality assure your projects before submitting them to your client. It's through our internal QA process that we stumbled upon the many accessibility issues in Storyline (such as this one, this one and this one). Some of the bugs have been addressed in Storyline 2, but most of the bugs remain in Storyline 1. So if you ever used Storyline 1 to create content for clients, I strongly recommend doing some NVDA tests on your published work.

mat corrado

Hi Kuriko!  I wanted to let you know that the only screen reader supported by Storyline is JAWS, as you can see here, in our technical specifications.  Storyline may work to some degree with NVDA, but it has not been verified by our QA staff.  

I'm not sure if the problems you are encountering happen in flash output, or in html5 output.  We have started our accessibility compliance in html5 output in Storyline 360.  

Hope this helps!

Kuriko A

Mat, I'm yet to find an example of an accessibility bug that appears in NVDA but does not occur in JAWS. Was the intention of your post here to try to infer that the bug does not exist when using JAWS? If so, you are incorrect. The bug I've described here certainly does occur in JAWS (as well as NVDA). Just check with Justin Grenier, Director of Technical Support at Articulate. He tested and confirmed this bug on 2 November 2016. But unfortunately, the priority of this bug has not been deemed high enough for the team to resolve. In my opinion, any bugs relating to accessibility for users with a disability should be of the highest priority, regardless of the number of developers who have reported them. Chances are, many of them have not realised this is even happening, so the people losing out are the end-users with a disability. 

In future, when someone posts about an accessibility bug which has been identified in NVDA, it would be great if you could take a couple of minutes to actually test the bug in JAWS first, before trying to claim that the issue is with the screen reader software and not with the Storyline software.  

And by the way, I have no intention of upgrading to Storyline 360 when Articulate has sold me two products already which do not work as intended. Instead of employing more tech support staff to resolve the bugs in the software we've already purchased, it would seem that the company's decided to just ditch the sinking ship and ask customers to buy a new product instead, which is promised to work a whole lot better! What confidence can users have that Storyline 360 will be any different, especially if the tech support team is still so scant that it cannot afford the time to fix the existing bugs? 

Mark C

I have now downloaded a trial version of Storyline 3 and upgraded my course to that to see if it works but still the same issue. I am running off a dead line of delivery of next Thursday and there is no way we will meet that having to use the work around to change every single button and re-link all states and triggers. Given this has been a known issue for quite some time I'm really disappointed that even Storyline 3 doesn't fix this issue.

Kuriko A

Hi Mark, good on you for having a try. I didn't even bother testing this in Storyline 3 because the Articulate tech team have already told me this is not a high priority issue. I agree it's very disappointing. 

We need more people to voice how important this issue is. The problem is that most Storyline users are simply not aware that their courses are not accessibility-compliant. 

Mark C

So I have managed to come up with another work around which actually works without having to delete the button. If you edit the state of the button and then add the ALT text to the image on the normal state, it works.  Whilst not ideal, at least this way you don't have to redo all the triggers etc. Hope that helps. This is still a bug that needs to be fixed though.

mat corrado

Thanks for posting that link, Matthew.

Yep, there's a bug around object states and alt text.  We are aware of it, and it is on our radar for fixing.  I will post any additional information as it becomes available.

Pam, if you'd like to attach your .story file, or submit it in a case here, I'm happy to have a look at your specific case.

Cody Tubbs

Has this issue been resolved? I am finding that JAWS screen reader is reading my alt text as "next button" even though I have assigned it something different. Same issue goes for my menu button and close button. Rather than reading the Accessibility Text it seems to default to what the button actually does (ie. "open menu button" - "close course button" - "next button" etc.).

Anyone else have this issue in JAWS? I'm having a hell of a time trying how to get my alternate languages to read not in English!

Ashley Terwilliger-Pollard

Hi Cody and Mark, 

Thanks for checking in on this. 

We were able to implement the fix for this issue in Storyline 3 and Storyline 360. It's not fixed in Storyline 2, but we continue to keep an eye on it,  how many customers are impacted and what impact it has on courses. 

Let me know if you have any other questions, and if you've not yet taken a look at the trial of Articulate 360 or Storyline 3 you can get started here! 


Mark C


I also reported this issue was still ongoing in Storyline 3 and in 360 when I last checked it earlier this year.

I dont thing the solution of buying a different version to fix a bug in the current version is a solution the problem. It is an advertised feature of Storyline 2 so should therefore be addressed or give everyone a free upgrade to 360. If the issue can’t be fixed.

It’s like buy a car and then finding out your speedometer isn’t working at certain speeds and the solution is to buy the latest model in order to fix the issue!!

Jothan Sargent

Hi all,

It seems the link to the video demo doesn't work anymore, so that is a bummer. We have had some experience with this problem in Storyline 3. It started out when we discovered that native Storyline buttons (specifically checkboxes and radio buttons) don't read their states (checked versus unchecked) properly in HTML5 output but they did read properly in the Flash output. We're testing with JAWS in Internet Explorer 11. In our testing it seems the problem was limited to the HTML5 output. We recognize that accessibility is new to HTML5 output in SL 3 so figured this would get fixed as time goes on.

We came up with a work-around for this that seems to work where we turn off accessibility on objects within all of the states of the button, put in an invisible rectangle within the button states that would function as the "hot area" of the button with no ALT text, and then assigned ALT text to the button instance itself not the objects within the states. What this means is we had to create our own checked and unchecked states for the buttons and manage those as a separate objects either on the base layer or as slide layers we could show and hide as needed (as opposed to doing this as button states as you would expect), so that is a pain but do-able. In other words, we wound up with one unchecked button with ALT text like "Radio button unchecked True" and another checked button with ALT text like "Radio button checked True" and we toggle the two using triggers.

Another work-around that seems to work is to put an invisible rectangle on top of a real button that has the triggers you originally had on the real button underneath it and remove accessibility from the real button and add the ALT text to what is now essentially an invisible button on top of your real button. We did also try using hotspots on buttons, but they don't seem to be accessible, but invisible shape objects like a rectangle work OK.

Based on what I'm reading in this thread the goal is to get to a situation where your button has a custom shape object in it somehow because that works whereas a button with just a graphic in it doesn't work.

One other note: Our work-around broke in Storyline 3 Update 2, but seems to work OK up until Storyline 3 Update 1 so we are kind of stuck at Update 1 for now.

Jeff Forrer

Another issue to add to this related to Accessibility is when you want to copy or import a slide from one file to another, the order of items in the Tab Order reset. 

The condition when this happens is when you have slides that have a set Tab Order which includes items on the slide master.  In this case we have a template file which we pull models from to build different modules which all share the same interface and slide master.   

When you import or copy a slide from the template (which has Tab Order set ahead of time) and bring that into a new module which is built off the template, the Tab Order does not hold, it reorders.  In this case whenever a new model is brought in, even coming from a file with the same Slide Master and components, the Tab order breaks, so it has to be reordered for all imported slides.

Crystal Horn

Hi Henri and Jeff.  Thanks for chiming in here.

Henri - thanks for staying on top of the custom navigation issue where you can use a keyboard to navigate using a custom button, even if it's disabled.  Our team is still reviewing this behavior, and the workaround we have currently is to use the built-in Next button if possible.  We'll provide an update when we can.

Jeff - can you let me know which version of Storyline you're using?  I tested this flow in Storyline 360 (3.9.13567.0), and the the imported slide kept the tab order.  These are the steps I took:

  1. Created a slide with master slide items and another item on the actual timeline.  Reordered the items in tab order.  Saved this project.
  2. Created a new project with its own content, and then imported the slide from the originally saved project.  Compared tab order.

Can you confirm your process?  Also, if you can share the original template project file (even if it's just pared down to one slide), I'll do some testing in my setup.

Thanks, all!

This discussion is closed. You can start a new discussion or contact Articulate Support.