Storyline and Screen Readers

May 09, 2019

Emily Hinteregger
By Emily Hinteregger

I am in need of guidance. I work for a University and accessibility is the #1 concern with creation of interactions within Storyline. I am working on a project currently where they would really like tabbed interactions from Storyline. Orginally we also had drag and drop activities but I removed them after receiving the feedback that they were not at all accessible. 

This is the feedback that I received about interaction with screen readers from the director of accessibility at the university after sending him a very basic tabbed interaction. I had removed all alt-tags from any decorative objects, only labeling the items that were clickable and the text that needed to be read. I published to Review 360 using the modern player and HTML5.

This is all the feedback I received:

  • Articulate relies on Flash, which is often a detriment to accessibility in itself - that is the case with these interaction
  • Play button does not have a label - user hears "untitled 0 button."
  • Activation of the unlabeled play button (pressing enter) does not automatically launch the next slide
  • The slide advances once the user presses the Control key after pressing the enter key (this is nonstandard)
  • When the new slide loads, there is no notification that a new slide has loaded
  • visually the user sees "click each phase to learn more," [this is the alternate text I added to any button or hotspot that opened a new layer] but there is not audible indication that something has occurred.
  • The buttons for each of the reactions are not read in the same order as presented visually [I now know how to fix this]
  • Upon attempted activation of one of the reactions, the screen reader is forced into forms mode and the item does not get activated.
  • Windows-based screen readers are unable to activate the buttons (NVDA and JAWS)
  • Keyboard only user would not be able activate the reactions either (there is no focus indicator, nor do the buttons seem to receive focus)

I'm about ready to have University scrap their Storyline subscription in favor of something accessible to screen readers (check your Universities requirements and I bet you too will need to switch to a different software), unless there is a solution to all of these issues. It seems like these are mostly back-end issues that I can't address, is that correct? 

If there is a solution - I have not found it - and would love a play-by-play.

Thanks in advance.

 

5 Replies
Crystal Horn
almost 5 years ago05/10/19 at 6:03 pm (UTC)

Hi, Emily. Thanks for sharing that feedback.

Storyline 360 supports authoring accessible content that can be used with JAWS 16 or later in these environments.

  • We support tabbing to objects listed in tab order, activating buttons with the space bar or enter key, and JAWS reading the alt-text of objects.
  • Publishing with the modern player, yields HTML5-only output, and your browsers Flash Player should not be referenced when the course is launched.

It sounds like you've identified areas that would improve your experience, like better labeling of the play button when a course launches, and audible notification of opening a layer or moving to the next slide beyond the course Title being read again.

Some of the issues you mentioned I'm not able to reproduce in an example file. We're happy to have a look at your project to see if we can offer any help! You can share it with us privately here, and we'll delete it when we're done troubleshooting.

In the meantime, we're working on a better player structure that'll provide industry-leading accessibility support. We have several enhancements planned to comply with the latest accessibility standards across more screen readers and web browsers. I don't have an ETA yet, but we're excited to announce as these features are improved.

Simon Taghioff
almost 5 years ago05/17/19 at 10:11 am (UTC)

Hi everyone,

I wanted to share a few more details on our work in this area.

First up, we strongly believe that as many people as possible should be able to fully experience training created with our tools.

As accessibility requirements and standards have evolved, we recognize that our authors have found it increasingly challenging to create accessible content using our authoring tools.

We’ve been investing in accessibility improvements in our tools for some time. Closed captions, text-to-speech, and improved management of alt text and captions in media library are a few examples in Storyline alone.

We’ve also been working behind the scenes for well over a year to fundamentally restructure our published output. We’re working on additional accessibility features for Storyline, with the goal of making it fully compliant with WCAG 2.1 and s.508:

  • Our initial focus is the player frame. We’re improving the way learners move around a course, ensuring that all controls, menus, and dialogs are correctly labeled and structured. This work has been progressing well and we’re aiming to have an early version in Beta in Q3.
  • Next, we’ll tackle the slide content itself, starting with the basics (reading text, navigation, layer interactions) before addressing specific areas like quizzing, interactions, and media playback.
  • Finally, we’ll be improving key workflows in Storyline to expose new functionality and make it easier to create inclusive courses without a lot of extra effort.

We’ve had ongoing conversations with our customers and will be addressing a number of longstanding accessibility issues and reported bugs as part of this work. We’ll also be expanding our official support for screen readers beyond JAWS to include other popular tools on desktop and mobile.

We’re not ready to talk about timings in detail yet, but we’re planning to roll out improvements in phases, starting with the player frame. We’re aiming to get the first improvements released towards the end of this year.

We’re committed to making Storyline courses accessible to learners with a wide range of abilities and needs and look forward to working with our customers to get there.

If you're interested in participating in the Beta process when we're ready to start testing, please email beta@articulate.com.

- Simon

Katie Bush
over 4 years ago10/08/19 at 2:29 pm (UTC)

Another item I noticed that could be added to the to-do list is that text/number entry boxes are not tied to a label. If you have one entry box per slide, you can get by because you can just have text before it to describe what the box is for, but if you have more than one entry field, there is no way I can find to associate a label.  The screen reader does announce it as an entry box but the screen reader user would have no idea what it was associated with.

Fixing this would help support things like WCAG 1.3.5 Identify Input Purpose and 4.1.2 Name, Role, Value.

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