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

Hi R M, 

I was able to do some testing and found that the 2 issues noted by Kuriko do NOT happen on custom shapes that act as buttons (with states).   I have opened a new case for you to verify the details of the issue with grouped objects.  You should have received an email from Articulate support.    

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.

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!

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? 

Is there an ETA on when this bug will be fixed? I have a built a large course for a client and it is going live in two weeks - we simply do not have the man hours to change every button on every page with this workaround. Also not to mention having to create triggers etc. associated with each button. 

Hi Mark, 

Thanks for reaching out here. I opened up a Support case on your behalf so that we could take a look at what you're seeing to ensure it matches the bugs reported here by Kuriko. You'll get an email from our team (Support@articulate.com) shortly to request some additional information. 

Hi Mark! Thanks for letting the Articulate team know that this bug is important. If more people express concern about it, then maybe the tech support team will decide to dedicate some time to actually fixing it.  

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.

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. 

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.

I too am having the same issue with Storyline 360. I did try Mark's suggestion to add the alt text in the normal state, however, alt text still does not appear when I publish. Should it?

Thanks,

Pam

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.

Thanks Mat. I've just been getting familiar with Storyline 360 and this is just a demo presentation I created. I've attached it for your perusal.

Cheers,

Pam

Thanks, Pam.  Can you attach your .story project file, please?  That way i can see "behind the scenes".  :)

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!

I’m still waiting for articulate to come back to me from Start if this year.

The way around it is to edit the state and then put the alt text on the object in the state.

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! 

Hi

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!!

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.

What about Storyline 2?

Seems ridiculous to have to pay to upgrade to Storyline 3 when it is a feature in Storyline 2 that should be working.

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.

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!