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

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.

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.

Thanks!

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.

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.

• Check out the release notes for more details.
• Follow these steps to see all the latest enhancements.

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

Woo-hoo! Thanks for the update, Katie.

Hi 

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.

Andrew

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.

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

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.

Andrew

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:

• Design for Mobility Impairments
  

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