Storyline Player Navigation Button Accessibility Issue when using NVDA screen-reader

NVDA (https://www.nvaccess.org/) reads out the following for the Previous and Next buttons of the Storyline 360 Player:

  • Classic Player: "Prev button" and "Next button",
  • Modern Player: "Button" and "Button"

Problem with Classic Player, "Prev" could be difficult to understand for people with cognitive disability.

Problem with Modern Player, having non-descriptive buttons confuse people using screen readers.

Can JAWS users please let me know whether that screen reader reads the same output as NVDA?

I know Articulate states that it supports JAWS but NVDA has 31.9% market share (https://webaim.org/projects/screenreadersurvey7/#primary).

Articulate, could you please improve your product (and yes, I will post this to the feature request form) so that we can all make the world a little better?

17 Replies
Ashley Terwilliger-Pollard

Hi Alfred,

We're all for making the world a better place! I know accessibility issues have been at the forefront of recent conversations, so I wanted to give this a test. 

I took a quick look at this using the trial of JAWS and a course I published here (with puppy photos as that also makes the world better), and I heard the same thing. That it only reads out "Button - Press Enter to activate" when on the Previous and Next buttons.

I'll share this example with my team to take a look at and will be in touch with you here as soon as I can! 

Eleanor Cotton

Let me add my vote to ensuring that Storyline is accessible using the top 3 screen readers: JAWS, NVDA and Voiceover for Mac. All three of these are increasingly popular as shown in the original post's survey link.

I created a simple quiz with Storyline 360 and a blind colleague using Voiceover demonstrated that the tab order was wrong, there was no indication when a new slide appeared, and the three methods for selecting a button only worked sporadically. 

This really needs to be a priority.

Robert Lengacher

DISCLAIMER: I'm not sharing the following information as a workaround, but as information that will hopefully make it to the developers so they can make the appropriate changes. I've submitted this as a bug report too, and Vevette Chua is checking on it. I'll post any updates when I receive them.

Hi all. I've figured out part of the problem causing this issue when publishing for Web (not sure about LMS publishing). In the story_html5.html file the two problematic elements for the PREV and NEXT buttons respectively are 

<span class="text" data-reactid=".0.0.5.4.3.6.0.1.1">PREV</span>

and 

<span class="text" data-reactid=".0.0.5.4.3.6.0.2.0">NEXT</span>

when I change "text" to "accessibility" in each element, the screen reader will say whatever text you've designated in the Player > Text Labels table for each button. The modified lines that work look like this.

<span class="accessibility" data-reactid=".0.0.5.4.3.6.0.1.1">PREV</span>

and 

<span class="accessibility" data-reactid=".0.0.5.4.3.6.0.2.0">NEXT</span>

BUT. These are generated automatically by scripts in the app.min.js file.

t.createElement("span",{className:"text"},this.state.i18nprev))

and

t.createElement("span",{className:"text"},this.state.i18nnext)

In that file, when I changed "text" to "accessibility" in those two lines of code, saved that file, and reloaded the module, the story_html5.html file had the "good" lines shown above. HOWEVER, I'm pretty sure that manually changing those lines in the .js file is not a good idea.  

 

Joanne Chen

Hi Ashley,

I am still in the very beginning of the accessibility project. I am doing a lot of testing  and so far it works ok for NVDA readers when using Classic Player. But we haven't had any disabled person doing a pilot test and I am not sure what issues might be raised then. My goal isn't just to create an accessibility e-learning course but a quality e-learning course for disabled person. There are a lot of challenges doing this project, but they will become great experiences that I might be able to share after the project. 

Joanne Chen

I found that NVDA will invalid some keyborad triggers. For example, I set PageDown key to skip to next slide and it works well. However, when I turned on NVDA, it won't work anymore. I guess it  was because of some conflict between SL keyboard triggers and NVDA. I try to use some other not so popular keys but still don't get it worked with NVDA.

Christine te Bogt

Other accessibility issues arise when viewing courses in the mobile player:

1. Custom tab order is ignored, objects that are set as "not be visible by accessibility tools" reappear in the tab order.

2. Selecting buttons with a double tap (as per the ALT text instruction) does not function.  

3. Menu and navigation buttons only read as "button" (no menu, pervious, or next descriptor).

Note: In the desktop player the custom tab order is preserved and the space bar/enter key function to select buttons as normal. 

Fixing the accessibility problems with with both players really needs to be a priority.

 

Ashley Terwilliger-Pollard

Hi Christine,

Are you using the Articulate Mobile Player (AMP) or the HTML5 output on a mobile device? The AMP isn't supported for the accessibility features which you'll see outlined here.

For a mobile device and browser, can you let me know which of the supported devices or browsers you're using? 

Patrice Sigmon

Is there any new information pertaining to this thread. I started testing a module using NVDA today and discovered that if I remove the "PREV" and "NEXT" text from the buttons in the SL3 player (leaving only the chevrons), then NVDA only speaks "button" even though the Player text label setting for "Next button screen reader verbiage" is "next" and "Previous button screen reader verbiage" is "previous". We like to use the Prev/Next buttons with just the chevrons to make translations a bit less of a hassle.

The obvious fix for the time being is to put the text back on the buttons. I'd welcome any updates you can provide.

Lauren Connelly

Hello Patrice!

I'm happy to help! This is a current bug we've logged for Storyline 3 where a screen reader doesn't read the correct "Next button screen reader verbiage". 

We are continuously tracking customer impact for accessibility improvements in Storyline 3, so I've added your comments to our active report. 

We don't have any other workarounds listed, so I welcome our community to share any tips!