Visually disabled learners are currently unable to differentiate between an active and a disabled "next" button

May 19, 2020


I filed a support request related to this issue back in March. The case number is: 02189124. In that support request, I stated, "JAWS screen reader does not read a disabled "Next" button as being disabled. This occurs with either the classic or modern player. I'm using JAWS Professional Edition 2018.1811.30 ILM."

Shortly after I filed the support request, I received a notification that a "feature request" (#02189206) had been added on my behalf.

I also filed several other accessibility bugs that occurred after the new "accessible player" was released. For the record, I was an active participant in the Beta testing of the accessible player and spent a lot of personal time helping to improve your product.

The 3.40.22208.0 release of Storyline 360 addresses all of my filed accessibility bugs except the one I'm writing to you about. Unfortunately, I've been unable to release courses using the new accessible player because there are still accessibility bugs in it that didn't exist before the accessible player. Specifically, I've been having to publish courses using the 3.35.21017.0 version of Storyline 360, but frankly I'm worried that I won't have that option much longer...

So, I'm a little desperate to get this issue resolved. 

Basically, I disable the Next button until a learner has completed a video, exercise, etc. Once they complete the required content, I set the Next button to the "normal" state. A sighted user has no problem seeing that the navigation is now available. A visually disabled user, however, currently has no way of knowing that the Next button is disabled or enabled. The Alt Text is the same for both states.

This wasn't the case until version 3.36.21289.0 (the "accessible player") was released.

Please take a look at this video and you'll see/hear what I mean:

You'll hear that JAWS reads the disabled Next button as "unavailable". I also tested in VoiceOver and it reads it as "dimmed."

You can see this for yourself if you have a screen reader here:

As it stands right now, a visually disabled user has NO WAY of knowing when the Next button is available to them. This is a major shortcoming of the "accessible player" and I can't use the current version of Storyline until this gets resolved. PLEASE HELP!

10 Replies
Lauren Connelly

Hi Enrich!

Thank you for sharing more details with us. We do have this logged as a bug when using locked navigation in the player, Next and Prev button states are not announced correctly.

It's in the hands of our Engineering team so when we have an update, we'll make sure to report back to this discussion. Right now, we've logged that this issue occurs with JAWS and NVDA in Update 39 and 40. Just to confirm, is that what you're noticing as well?

Thank you for taking the time to share this with us! It's important that we continue tracking what our customers are seeing on their end.

Erich Renken

Yes, that's what I'm seeing, as well. It's also happening when using VoiceOver.

Lauren, do you know if we'll still be able to install older versions of Storyline that aren't showing in the Articulate app like I pictured above? I'm concerned that I won't have access to update 35 if there's another release before this issue is resolved.


Lauren Connelly

Hi Enrich!

I've added VoiceOver to our report, thanks!

We display the past 5 updates for users to rollback to. We are currently on Storyline 360 Update 40 (Build 3.40.22208.0) so when we release our next update then Update 35 will be removed. 

We encourage authors who are building courses to meet WCAG standards to use at minimum Update 36 because Update 35 is no longer compliant with the current standards. For example, in Update 35 and previous versions, screen reader users and keyboard users tabbed through every button and menu item in the player. This approach was burdensome and inconsistent with other web navigation experiences, particularly for screen reader users. In Update 36-Update 40, the course player has been re-organized to make it easier for users of accessibility aids to understand where they are and move around quickly. This includes the use of ARIA landmarks and regions as appropriate (e.g. navigation regions), as well as restructuring of the player behind the scenes into discrete areas of functionality that follow a consistent order and hierarchy.

We are nowhere near the end of our accessibility journey and will continue tracking customer input. We appreciate you taking the time to share how this bug is impacting your courses. 

This bug is in the hands of our skilled Engineering team, so once I have an update I'll let you know in this discussion.

Katie Riggio

Good morning news, Enrich! 🗞

Update 41 for Storyline 360 is live: We fixed the issue where screen readers didn't announce disabled states for player navigation buttons.

Thank you for bringing this forward, and we're here if you have any questions! 

Andrew Lloyd


I have a question about accessibility, in particular about being able to build an accessible drag and drop. I have read an article on the forum by a Sally Wiedenbeck, where she describes a series of triggers that create an accessible drag and drop but when you open the example file she doesn't appear to have the 'Form/Slide View functionality visible or available. I do have that, so does that mean I am scuppered from the start, that I won't be able to recreate what she has done if that makes sense?


Happy to provide more details if needed.



Katie Riggio

Hi Andrew,

Happy to lend a hand! Since drag-and-drop interactions require the use of a mouse, we don't recommend them for courses that must comply with Section 508 accessibility guidelines.

Sally's example was built in a standard, non-question slide. These slides do not have a Form View.

Did you recreate the steps in a freeform quiz question? I'm not sure if this will affect the functionality, but you can head over to the Insert tab and click Remove Freeform. This will convert the freeform interaction to a standard slide. 

For folks following along, Andrew is referring to this custom community idea: Build an Accessible Drag and Drop Interaction in Storyline

A few more possible alternatives:

  • Rather than using matching drag-and-drop interaction, consider a matching drop-down interaction instead since it's keyboard-accessible.
  • Add a link that opens a layer with a text-based alternative for a freeform drag-and-drop interaction.
  • Let learners choose a slider alternative for a hotspot interaction, since sliders respond to the arrow keys on your keyboard.
Andrew Lloyd

Hi Katie,


Thank you for that. 

I am relatively new to Storyline (SL), so I am unsure about some of your terminology. Basically, a colleague of mine has built a set of templates, so that people using SL in my company all have the same standards.

So the question slides we have come ready built. I don't think we're using the built-in D&Ds.

Your suggestions are interesting; we have a dropdown interaction and will try that first and then maybe try the others. Thank you for those.

One question I had about Sally's piece was whether she had built a single Drag and Drop slide that worked for a mouse and for keyboard interactions, or, whether she had built a D&D that was only usable by a keyboard. I guess it must be the first one. So many questions.

Thanks for your reply and suggestions.





Andrew Lloyd

Hi Katie,


One other query. Your comment here:

'Add a link that opens a layer with a text-based alternative for a freeform drag-and-drop interaction.'

With some clients we do supply a pdf of the interaction that describes what is going on but we're currently working with a client where we are trying to avoid that and use only accessible activities from SL. Was that the kind of thing you had in mind (a transcript) in your comment above.



Ren Gomez

Hi Andrew,

Happy to help chime into your additional questions! For your first one:

One question I had about Sally's piece was whether she had built a single Drag and Drop slide that worked for a mouse and keyboard interactions, or whether she had built a D&D that was only usable by a keyboard.

I haven't had a chance to dig into the file, but from the description in her post to make it accessible, it seems the interaction should be able to be completed with a keyboard. It looks like you've had some discussion with her, so I'd continue to get that clarified.

What did you mean by "Add a link that opens a layer with a text-based alternative for a freeform drag-and-drop interaction?"

I believe Katie was referring to this article that covers some alternatives, as well as provides helpful, accessible design tips:

Take a look and see if the resource provides some insight!

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