I'm having a difficult time getting my published Articulate Storyline 2 and 3 courses to "play nicely" with a screen reader. I know that according to Articulate's accessibility statement "Storyline supports the JAWS screen reader and makes it easy for course authors to create large text versions of slides." I'm having a hard time, however, designing my courses in a way that supports the screen reader. I find the screen reader competes directly with the audio from the published course. Has anyone else had trouble with this? Has anyone found an effective design solution for end users both with and without screen readers?
We sometimes put a slide up front in our courses asking the student if they are using a screen reader. If they select "Yes", then we turn the audio off for the slides in a course.
If you have any timed animation to the timeline, just watch you don't bury any important information at the very end.
If its an option for you, upgrade to 360. It does a better job with 508.
In my experience, the screen reader doesn't start reading things until I tab to a focus item.
We put a slide at the very beginning of all our courses that says there is narration included, and instructions for those using screen readers to wait until the narration completes before tabbing through focus items.
We avoid having slides auto-advance, especially if there is information we want to make sure that the visually impared learner focuses on.
I think the last key thing to remember is to take all the "fluff" out of the tab order. If your narrator already covered the bullets on the screen, then including the bullets in your tab order becomes redundant. You can take those bullets out of the tab order, knowing that your narrator has covered them.
This is helpful, especially about giving instructions for those with screen readers to wait for narration to complete until tabbing over. Thanks, Joe, for some practical tips.
Unfortunately it's not an option to upgrade to 360 and it's too bad to see that suggested (twice). It shouldn't matter what version I'm using; I started with SL2 and according to Articulate's accessibility statement it was ADA compliant/accessible with JAWS. Anyways, moving on...
I'm now using SL3. Thanks for suggestion about a slide at the beginning of the course. When turning off the audio for those just using screen readers, do you "branch" the content so that you have two sets of identical slides with the only difference being that one set of slides has audio and the other doesn't? Or do you use a trigger to turn off the audio moving forward? If it's the latter, any practical tips you could offer on exactly how to do that would be great!
Hi there. I'm with Lindsay on this one. I don't have a choice of software and I'm using SL3. Would love to know the answer to LIndsay's question. Do you need to branch to non audio slides or can you turn audio off for all slides once that option has been selected?
I just received a question from a student today regarding using his screen reader (waiting for him to tell me exactly what he is using). He says he needs to highlight the text on the slides for the reader to work, and apparently so far this is not working for him. Does anyone know what I would have to do to make this work for him? Or a work around? Thank you!
The screen reader I'm most familiar with (JAWS) defaults to reading assets/screen content in order from left to right, top to bottom. To toggle between the assets, the learner uses the Tab button. You should see a yellow outline pop up on the asset that the screen reader is reading. It'll read text, but any graphics/pictures/etc need Alt text (which is easy to add in SL3). SL3 also has an option where you can change the order of the assets for the screen reader. However, you can only change the order of the assets on the slide itself. The screen reader by default will also read some (not all) of the player elements. So it will read the titles of Menu, Notes, Resources, but it won't actually read the notes. It's a little funky. My work around moving forward is to build out navigational elements that you would typically find in the player in the slides themselves. Additionally, I worked with a student who used a screen reader and she said it would be easier to just have a text only version of the course (just like you would have a text only version of a website), created in Word using headings and subheadings for ease of use. In my eyes, that's not ideal, because it's not designed for all and accessible for those who need, but rather you're just creating another version that doesn't have any of the interactive elements at all. Check Articulate's accessibility guidelines, because they have a lot of functions that cannot be designed to be accessible with screen readers (if I'm remembering correctly, drag and drop is one). I'm still not thrilled with the screen reader issue that I originally brought up. Moving forward, I'll design my slides very differently and chunk out my content into smaller pieces and upload in our new LMS powered by Moodle, which is much more screen-reader friendly.
9 Replies
We sometimes put a slide up front in our courses asking the student if they are using a screen reader. If they select "Yes", then we turn the audio off for the slides in a course.
If you have any timed animation to the timeline, just watch you don't bury any important information at the very end.
If its an option for you, upgrade to 360. It does a better job with 508.
In my experience, the screen reader doesn't start reading things until I tab to a focus item.
We put a slide at the very beginning of all our courses that says there is narration included, and instructions for those using screen readers to wait until the narration completes before tabbing through focus items.
We avoid having slides auto-advance, especially if there is information we want to make sure that the visually impared learner focuses on.
I think the last key thing to remember is to take all the "fluff" out of the tab order. If your narrator already covered the bullets on the screen, then including the bullets in your tab order becomes redundant. You can take those bullets out of the tab order, knowing that your narrator has covered them.
This is helpful, especially about giving instructions for those with screen readers to wait for narration to complete until tabbing over. Thanks, Joe, for some practical tips.
Unfortunately it's not an option to upgrade to 360 and it's too bad to see that suggested (twice). It shouldn't matter what version I'm using; I started with SL2 and according to Articulate's accessibility statement it was ADA compliant/accessible with JAWS. Anyways, moving on...
I'm now using SL3. Thanks for suggestion about a slide at the beginning of the course. When turning off the audio for those just using screen readers, do you "branch" the content so that you have two sets of identical slides with the only difference being that one set of slides has audio and the other doesn't? Or do you use a trigger to turn off the audio moving forward? If it's the latter, any practical tips you could offer on exactly how to do that would be great!
Thanks again, Bob.
I do like the idea of a hidden image in place of a slide. I'll have to play around with both and see what I like better. Thanks, Matthew!
Hi there. I'm with Lindsay on this one. I don't have a choice of software and I'm using SL3. Would love to know the answer to LIndsay's question. Do you need to branch to non audio slides or can you turn audio off for all slides once that option has been selected?
Wonderful. Thank you Matthew. Have just tested it and it works beautifully!
I just received a question from a student today regarding using his screen reader (waiting for him to tell me exactly what he is using). He says he needs to highlight the text on the slides for the reader to work, and apparently so far this is not working for him. Does anyone know what I would have to do to make this work for him? Or a work around? Thank you!
The screen reader I'm most familiar with (JAWS) defaults to reading assets/screen content in order from left to right, top to bottom. To toggle between the assets, the learner uses the Tab button. You should see a yellow outline pop up on the asset that the screen reader is reading. It'll read text, but any graphics/pictures/etc need Alt text (which is easy to add in SL3). SL3 also has an option where you can change the order of the assets for the screen reader. However, you can only change the order of the assets on the slide itself. The screen reader by default will also read some (not all) of the player elements. So it will read the titles of Menu, Notes, Resources, but it won't actually read the notes. It's a little funky. My work around moving forward is to build out navigational elements that you would typically find in the player in the slides themselves. Additionally, I worked with a student who used a screen reader and she said it would be easier to just have a text only version of the course (just like you would have a text only version of a website), created in Word using headings and subheadings for ease of use. In my eyes, that's not ideal, because it's not designed for all and accessible for those who need, but rather you're just creating another version that doesn't have any of the interactive elements at all. Check Articulate's accessibility guidelines, because they have a lot of functions that cannot be designed to be accessible with screen readers (if I'm remembering correctly, drag and drop is one). I'm still not thrilled with the screen reader issue that I originally brought up. Moving forward, I'll design my slides very differently and chunk out my content into smaller pieces and upload in our new LMS powered by Moodle, which is much more screen-reader friendly.
This discussion is closed. You can start a new discussion or contact Articulate Support.