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

Hi Jeff, 

Did you mean to share your template, I didn't see it attached here?

I'd love to take a look at it, as I tried to follow your steps (listed out below) and my results:

1.  Create a new project (let's call it File A) with Slide master elements and individual items on the slide, with a custom tab order. 
2. Create a duplicate copy of that project (called File B). 
3. Opened File B and chose to import in a few slides from File A - (so now we've got a File BA) noted that the tab order from File a is respected and carried over
4. Realized I missed a few slides, so imported a couple slides from File A into the combined File BA. - those slides also had the same tab order as the original File A 
5. Just for fun - I even did the reverse. I opened File A, and imported in all the slides from File BA...tab order consistent across all of them. 

Even if you can't share the slides, a quick screen recording may help us spot something different in our testing steps. If you need to share the file privately, let me know and I'll start a support case for you. 

Hello.  Thanks for your response, I will get you a file or screen recording this week.  We had to revert to older Storyline 3 version to help with this and other issues.  I will get you something this week.Thanks

Hello Ashley.One other note, when you import the slide from the other file, did you get a duplicate slide master?  In our case we do, so we apply layout of imported slide to slide master already in the file we are in, and delete the one that came with it from the other file.  Even though they are the same, it brings a copy of the slide master over from the other file.  Once we apply the slide master to the imported slide, that is when the accessibility gets reordered.Let me know your thoughts.  Thx.  I can record a video as well.

Hi Jeff, 

Yes, when you import a set of slides, we're going to carry over the slide masters...even if they're the exact same set up in the other file. Storyline is pretty smart...but not that smart to know that they're the same thing. 😉 

Deleting and applying a new master may be the cause here, and then it makes sense that the tab order would get reset as Storyline is treating it as a new set of items and going back to the default.  I would love to see your video to confirm and watch the steps your going through...but it's making a bit more sense now what's happening! 

Just blown away and really disheartened by the lack of consistent progress or honest communication from Articulate. Folks with disabilities deserve WAY better. The legal liability here is astounding. 

I am also having the same issue.  My team is in the process of converting our SL2 projects into SL3 because SL3 fixes the issues with the feedback layer focus and JAWS.  However, we are now having to manually fix every close button on every slide (depending on the project I am talking hundreds of manual actions) because the Alt Text on the states doesn't pick up the alt text on timeline button.  Any idea when a fix will be made?  This is ridiculously time consuming.

Hi Erin, 

Two of the issues discussed here have already been fixed in Storyline 360, and so those fixes will be in the next update of Storyline 3 (scheduled to be released early this year, 2018). They are:

• Fixed how JAWS 18 kept reading "not checked" even after making a selection to a question in the HTML5 output
•  Fixed how the JAWS screen reader is not recognizing the selected state of a object

The issue with the disabled custom buttons still being accessible through keyboard navigation is something our team is continuing to investigate so we'll keep you posted here. 

Hi Erin, 

There have been a few issues reported here. Can you verify what update of Storyline 3 you are using. Our current is Build 3.2.13213.0.

Hi Leslie,

I am using SL3 Update 2

[cid:image001.png@01D38F76.30B81680]

Here are a few discussion about the issue on Articulate's website.

https://community.articulate.com/discussions/articulate-storyline/warning-accessibility-bug-in-storyline-wcag-508-compliance#reply-405619

https://community.articulate.com/discussions/articulate-storyline/screen-reader-accessibility-for-button-states

https://community.articulate.com/discussions/articulate-storyline/alt-text-problems

https://community.articulate.com/discussions/articulate-storyline/screen-reader-accessibility-for-button-states

Thanks,

Erin

Hi Erin,

Taking a look at all the ones you linked too, I think you're looking for this one: 

•  Fixed how the JAWS screen reader is not recognizing the selected state of a object

That was fixed in Storyline 360, and that fix will be released in the next update of Storyline 3. I don't have a definitive date on the release of that yet, but we're looking at early this year. 

We'll certainly post here once it's available! 

If that's not the issue you're running into, I'd love to have you work with our team one on one. This discussion has gotten a bit long, and I don't want your issue to get lost! 

Just the messenger, Matthew! 😉 But I'll pass along your thanks to the team! 

Mark, so nice that you posted the comment, "The way around it is to edit the state and then put the alt text on the object in the state."  We have an interaction with pictures and NVDA keep reading every picture as "picture 2."  Could NOT figure out where the words "picture 2" were coming from. Now it reads the alt text of picture's selected state.  It works beautifully with NVDA.

Hi Ashley Terwilliger and others. We're also finding that the original issue within this post hasn't been fixed in Storyline 360. Any update on when we can expect a fix for the fix?!

Hi Jackie,

I see that you've reached out to our support team, which is very helpful. I encourage you to continue working with Chino.

Following up on the fix for this issue. My team is on pause for conversion from SL2 to SL3 which we need to do for 508 compliancy. I don't want them to convert because the hassle of changing every single "close button" is insane! We are talking about 50-100 manual actions per project and we have over 200+.  See my post from 3 months ago.  I have SL3, not 360.

Thanks

Hi Erin,

I see that Ashley responded to your post above here.

I see where Alyssa replied to another post of yours here as well, so sounds like you may be experiencing a different issue that we are still looking into.

Hi Ashley, 

I have previously tested this in Storyline 360 trial and also Storyline 3 and it  is still not fixed.

Hi Leslie,

Thanks for the quick reply.  The last thing I see is from Ashely Terwilliger (Staff) from 3 months ago which states "The issues was fixed in 360 and a release is the next update of SL3 is coming but we don't have a definitive date, we are looking at early this year.

Just for clarification, the issue we are having is when we convert our SL2 projects to SL3 we have several layers on each slide which include close buttons.  Once the project is converted from SL2 to SL3, the close buttons no longer read close, they read "button 2 button" when using JAWS.  Apparently the conversion from 2 to 3 changes the alt text in the states.  We know how to manually fix it. We have to go into each state of each close button and manually change the Alt Text from "Button 2 button" to "close".  The issue is we are talking about around 100+ manually actions on over 200+ projects.  We simply don't have the man hours to make these adjustments.

Let me know if you would like an example to test with JAWS.

Thank you

Hi Erin,

Thanks for popping in with some additional details.

I'm not sure I'm fully understanding the issue your are seeing and I want to be sure we do have this reported.

Would you be able to share a sample .story file from Storyline 2 since you mention it is working correctly? We could then update to Storyline 3 for testing.

If you cannot share here in the forums, I recommend sharing here privately so that we can prevent any further confusion as this thread grows.

Leslie,

What's happening is in our template in SL2 we have close buttons that have Alt text on the timeline layer and nothing on the state layers (i.e. normal, hover, visited, etc.) and JAWS reads everything fine.  When we convert our projects to SL3, to conversion adds the words "button 2" "button 3" "button 4'' to the states for the close button. When JAWS first gets to the slide the focus is on the "normal" state which reads "button 2" instead of close. Every time we convert a project we have to manually edit every close button on every slide.

See images and projects uploaded

Hi Erin - perfect job explaining what you're seeing.  I was easily able to replicate this issue in the conversion of your project to SL3 on my end.

We have this behavior documented, and we're working to prioritize it based on impact.  I've included your experience in our record, especially the effort it takes on your end to manually adjust the alt text.

We'll update this discussion with any new information as we get it.

Crystal, We had a similar situation in 360. I would think this applies to Erin's issue - assuming I'm reading her procedure correctly. We fixed a single "Close" button and then copied and pasted it across every slide where it appeared. Copy and paste worked fine once a single source button was corrected. We did spot check it initially to make sure it worked so we didn't need to physically edit every button. It too had to be done across many slides but it went quickly using that process.

We are still having this issue, we use Storyline 360 and JAWS as a reader. It is reading the image file name instead of the alt tag. The work around that we had to do was to delete the visibility of all the images, the triggers, and set buttons set back to none. Then we followed Jonathan's advice of putting "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." This is very tedious work and let me tell you that our team is not happy of having to have to redo so much work because this feature is not working correctly and it has been a known issue for over a year. Please get this bug fixed! 

I was able to fix my issues for mac voiceover with the above suggestion (search "button 2 button" on page 2 of this thread). I did not go into all of the button states to add the alt-text, just the normal and hover states. Thanks.