Accessibility

Hi, Tom!

One approach I've played with is to have a mute button available on slide 1 for non-sighted learners to click that would turn off the audio on the entire project. (Unfortunately, this involves using triggers on every slide to individually mute all instances of regular narration, as there is no global "mute" setting that I'm aware of.)

With the regular narration muted, you can then set up a JAWS-screen-reader version of the narration on every slide, which only the screen-reader users would be able to hear. This version of narration would be associated with one or more objects on the screen. I've embellished these slide narratives to include a description of the scene, the names of the characters, the dialog, and the instructions for what to do next. 

Another key consideration I discovered is this: By assigning all of the screen-reader information to the fewest number of objects possible (and disabling the visibility of the other objects for purposes of being "seen" by the screen reader), the non-sighted user can hear the information in a smoother way. Otherwise, the user would need to tab all around the screen "looking for" objects that have associated screen reader information. This can result in a rather jumbled listening experience because there is no way to set a custom tab order in Storyline.

The above method was how I was able to get a semi-decent listening result from JAWS, but perhaps others will have more elegant solutions to offer. I wish you all the best with your accessibility projects!

Cheers,
Adele

TL;DR: Use a transcript and closed captions.

_________________________________________________

Setting self-voicing content to automatically mute is a nice idea. It's something you might want to test with your audience as it's not common. Screen reader users consume audio mad-fast (up to and beyond 1000 words per minute). So us mere mortals with regular sight read WAY too slow for most seasoned reader users. The speed at which most screen reader users absorb audio information is super human amazing. Seriously. Something to consider.

This, however, is a little misleading:

"Speaking to our accessibility expert here, he has said the narration must match the text as closely as possible in order to qualify."

I think I see what the expert is saying but without additional details, your design efforts could reduce instructional effectiveness while not making the product more accessible at all. There are some common misconceptions around narration and about accessibility all-together. And a few experts around that propagate misconceptions by either misunderstanding the intent of the requirements or not explaining things well.

There are a broad array of impairments and challenges that can make information more difficult for some than for others. Hearing and sight impairments are just two of those. To make things really accessible (not just compliant) working through a matrix of "we have this" mapped to "here's how we're going to convey that to folks with this challenge (physical or environmental)"

I see lots of folks fall into the "make it accessible for screen readers" trap and miss the rest of the matrix. The goal of accessibility should be:
"Everyone can gain the same meaning from any media by applying roughly the same amount of effort."

In the case above, when you add audio as a strategy to an instructional package, you're likely NOT going to make that audio match exactly what's on the screen. You're probably not going to have much text on the screen at all in many cases. So what do you do when you have audio? How is someone with a hearing impairment or in an environment where they can't hear it going to get the same meaning? There are a LOT of ways to provide opportunities for everyone to gain the same meaning from the media.

I would consider doing all of these things to help. Keep in mind, this is just ONE facet of the things you can / should do to make your products more accessible.

• Add a transcript for each slide to accompany any media that contains audio. Some folks are going to want to read the whole thing to gain context or to review. This is helpful for everyone, not just people with disabilities. This is really easy to do in Storyline by adding your script to the notes field. I change the label from notes to transcript.
• Add closed captions. This isn't a built-in feature but is relatively easy to pull off. Make sure that the captions can be turned off. Open captions create another kind of accessibility challenge for some folks that have learning disabilities or attention problems (me, for example).

Should the transcript and closed captioning match the audio exactly? In most cases, yes. If you scripted your audio before recording, this is a natural fit. If you have someone on stage that speaks without a script and that was recorded, you might have the opportunity to make the captions convey meaning better and more concisely than in the audio. You'll see this when interpreters accompany a speaker. Rarely do folks interpret verbatim. They interpret for reasonable meaning given the constraints of the medium (time).

It's probably helpful to make yourself a table. Across one axis, list the general categories of impairment or environmental challenge. You could be general or break it down specifically (adding partial vision / hearing, etc..):

• Vision
• Partial vision
• Color Vision
• Hearing
• Partial hearing
• Motor
• Learning
• Prone to rage (Gamma overdose)

Across the other axis, list the types of mechanisms and media within your published output. Here's a partial list:

• Audio
• Images
• Video
• Interactions
• Structure
• Navigation
• Status
• Assessments
• Feedback

And for each cell in the table, list the challenges you're likely to encounter and some ideas for how you might deal with each one. Accessibility is a design challenge - and it can be a fun one to try to solve. 100% accessibility is a good aspirational goal, however impossible it is:) Honestly, 100% accessibility is impossible. We can get close, depending on how much time / energy we put into anticipating needs and testing.

Thank you guys so much for the detail of your replies. Lots to think about!

Thanks again!

Any recommendations to make a sign off acknowledgment in the course accessible?

Hi Michael,

Could you tell us how it's currently set up?

Hello Allison  -

Thank you for reminding me.   Below are 2 screens that I feel could be more accessible.
Is it in the narration, or should I consider completing rethinking the design.

In the Acknowledgement slide, the 1st option is narrated, but the second does not appear until it has been selected.  Once selected the second option is narrated.  At that point, the SUBMIT button is revealed and the narrator advised to click SUBMIT in the bottom right hand corner.

In this slide, there is narration, but I am concerned that a sight challenged learner would know about the 2 options.

Thank you!

Hi Michael!

I'm excited to step in and help with this accessibility build! Just to confirm, is everything included in the Tab Order and includes ALT text? My recommendation to make that slide more accessible is to add ALT text that explains that another option will be available once the first box is checked. 

For the second slide, I see what you're saying about the Target Size of the button which might be difficult for visually impaired users to access. I would look at these Success Criterion 2.5.5 Target Size in the WCAG Standards. In order to meet compliance, the size of the target for pointer inputs needs to be at least 44 by 44 CSS pixels. 

I also found this incredible article that offers a more visual explanation.

Please let me know if I can clarify anything Michael!

Hello Lauren  -

Very helpful  Thank you for your enthusiastic and generous response.