Accessibility: JAWS reader doesn't recognize new slide

We have tried several screen readers including JAWS, and we are unable to get Articulate to communicate with the screen reader that a new slide is ready to be read. The problem with this is that my peers who are blind don't know when they need to hit tab again in order for JAWS to read the new text boxes on the new slide. We had some courses that were required by law to publish quickly, so I created a work around by adding a ding to each page and asking my blind peers to tab through each page every time they heard a ding. However, this isn't the experience they have on webpages. JAWS recognizes (refreshes) every time something new is presented on a webpage, so it is an adjustment for the blind user when Storyline doesn't do this.

Does anyone have any ideas for this other than including an audio indicator (ding) as we did on our courses?

4 Replies
Ashley Terwilliger

Hi Sundae,

I'm certainly not an expert on 508 compliance or how JAWS behaves in other environments. I did want to point out our information on 508 here and I don't see anything about needing to indicate the new page or content? 

Are you using the next button to navigate? Could it be that once they've used that button then they know they're on the next screen? Storyline is pretty good at preloading content as described here so unless they're clicking through it very quickly on a slower connection I would think it would work ok. 

Sundae Delgado

Thanks Ashley. I should have clarified. This is a concern in both instances: When we use the next button for navigation and when we don't. However, as you guessed, it is much less of a concern when we use the next button. The main concern is on slides where we don't use the next button (i.e., when we transition to the next slide at the completion of media). The new slide appears, but my blind friends don't know that there are new text boxes describing the new screen content.

However, even when we have used the next button, the user who is blind says they aren't sure when the slide is complete. We use a lot of videos and audio. It goes silent, but they aren't necessarily sure it is time for them to push the next button unless we include a ding or audio of some sort.

Sundae Delgado

Also, I love the effort Articulate has put forward for accessibility. I found The 6 Best Practices For Designing Accessible ELearning to be a great resource that I share frequently with other designers. Thank you so very much for all of your hard work.

One other issue that I have encountered is that many in the blind community have told me that they are more inclined to use the down arrow rather than the tab key. Apparently, when they are navigating through websites using a screen reader, it is more common to use the down arrow rather than the tab key. However, I included these instructions upfront and my peers who are blind adjusted easily.

 

 

Ashley Terwilliger

Thanks Sundae for the update and I'm glad that article was helpful for you as well. 

With the exception of the accessibility elements mentioned in the 508 documentation, the majority of other items are authored controlled in terms of adding such things like the audio to play. If you need that on every slide, you could look at adding the sound file to a master slide and then using that across all your slides - you'll only be able to use one master per slide, so just keep that in mind if you had already set up masters.