I´m in the planning stages of creating a course that needs to be completely accessible and I have a question regarding the function of screen readers. If a slide has audio and the learner is using a screen reader, do they have control over when the screen reader starts reading? If we create the course with audio, I just want to make sure the audio and the screen reader won´t play at the same time. Hope my question makes sense!
I don't know much about screen readers so I am not sure I can be of much help. What I do know is that not all screen reader users use text-to-speech; many use braille output. Additionally, other types of accessibility tools - such as content highlighters and voice input apps - use the same techniques and APIs (eg. DOM, MSAA) that screen readers do, so any technique that "detects a screen reader" will likely detect these also - so you cannot assume that it means that the user is fully blind and using only speech.
My approach would be to default to audio narration OFF with a button that lets the visually enabled attendee turn ON the narration if they want to listen. That would avoid the conflict.
Defaulting to narration off and allowing visually enabled learners to toggle it on sounds like a good solution.
Thanks so much for this valuable input. I´m going to have to do more research on some of the things you mentioned above. I still have a lot to learn about accessibility!
I am wondering if you learned anything further about competing for audio when planning for accessibility. I have created a storyline 360 project that has audio narration and I don't want the screen reader to compete with the slide narration.
I was also wondering if there is any way to control the order in which the leaner tabs to each of the player features (i.e. volume, cc, resources, back, next...buttons) as well.
I've not yet gotten a definitive answer on this; however, I did recently update the accessibility for a voiced course, the client tested it with a screen reader and they were thrilled with the way it functioned. I did not do anything special with the audio in this course. My suspicion is that the user has control over when they start to tab through the elements. I base my alt text on this assumption- if the user has already listened to the audio, will the alt text enhance what they've read? Not sure if that's helpful...
Regarding having control over the order in which the learner tabs through the player features, hopefully a Hero will chime in as this is something I don't know.
Yes, the screen reader should allow the user to scroll though with keyboard shortcuts. The alt text might enhance what the user has already read if its relevant to emphasizing the learning/ topics.
Does the image help a person who can see the slide understand the material better? If so, the alt text would be important to emphasize the content in the same way.
Hi Nadia, having audio set to off as default for all accessible courses is best practice. Without a visual cue that there is audio coming, it often can give users a fright if content just plays and they are not prepared or volume is turned up high. Alternatively, if there is audio that does play automatically, then the user could be advised of this in the intro.
I am looking for a similar answer, however, I cannot set my audio to default to "off".
I have a course that needs to be accessible for all, without the need to select extra buttons/actions. The course covers universal design for learning, and talks about implementing accessibility for all without added effort from the user, so to have them push buttons for audio, captions etc. would go against the message being delivered.
The client wants audio to be automatic for all users (for those with mobility issues they don't want them to have to push a button/use the mouse to select the audio to play).
The client wants to know if the screen reader will overlap the automatic audio. If so, is there a way to delay the audio for ONLY those using a screen reader?
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.
Emily Hinteregger, I'm still learning how to create fully accessible courses myself, but with regards to comment #1, have you tried publishing to HTML 5 instead of Flash? That should take Flash out of the situation.
12 Replies
I don't know much about screen readers so I am not sure I can be of much help. What I do know is that not all screen reader users use text-to-speech; many use braille output. Additionally, other types of accessibility tools - such as content highlighters and voice input apps - use the same techniques and APIs (eg. DOM, MSAA) that screen readers do, so any technique that "detects a screen reader" will likely detect these also - so you cannot assume that it means that the user is fully blind and using only speech.
My approach would be to default to audio narration OFF with a button that lets the visually enabled attendee turn ON the narration if they want to listen. That would avoid the conflict.
Defaulting to narration off and allowing visually enabled learners to toggle it on sounds like a good solution.
Thanks so much for this valuable input. I´m going to have to do more research on some of the things you mentioned above. I still have a lot to learn about accessibility!
Hi Nadia,
I am wondering if you learned anything further about competing for audio when planning for accessibility. I have created a storyline 360 project that has audio narration and I don't want the screen reader to compete with the slide narration.
I was also wondering if there is any way to control the order in which the leaner tabs to each of the player features (i.e. volume, cc, resources, back, next...buttons) as well.
Have you learned any tips?
thanks,
Hi Fern,
I've not yet gotten a definitive answer on this; however, I did recently update the accessibility for a voiced course, the client tested it with a screen reader and they were thrilled with the way it functioned. I did not do anything special with the audio in this course. My suspicion is that the user has control over when they start to tab through the elements. I base my alt text on this assumption- if the user has already listened to the audio, will the alt text enhance what they've read? Not sure if that's helpful...
Regarding having control over the order in which the learner tabs through the player features, hopefully a Hero will chime in as this is something I don't know.
Thanks so much for your post. This is really helpful.
All the best with your future projects.
Same to you!
Yes, the screen reader should allow the user to scroll though with keyboard shortcuts. The alt text might enhance what the user has already read if its relevant to emphasizing the learning/ topics.
Does the image help a person who can see the slide understand the material better? If so, the alt text would be important to emphasize the content in the same way.
Hi Nadia, having audio set to off as default for all accessible courses is best practice. Without a visual cue that there is audio coming, it often can give users a fright if content just plays and they are not prepared or volume is turned up high. Alternatively, if there is audio that does play automatically, then the user could be advised of this in the intro.
I am looking for a similar answer, however, I cannot set my audio to default to "off".
I have a course that needs to be accessible for all, without the need to select extra buttons/actions. The course covers universal design for learning, and talks about implementing accessibility for all without added effort from the user, so to have them push buttons for audio, captions etc. would go against the message being delivered.
The client wants audio to be automatic for all users (for those with mobility issues they don't want them to have to push a button/use the mouse to select the audio to play).
The client wants to know if the screen reader will overlap the automatic audio. If so, is there a way to delay the audio for ONLY those using a screen reader?
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
Emily Hinteregger, I'm still learning how to create fully accessible courses myself, but with regards to comment #1, have you tried publishing to HTML 5 instead of Flash? That should take Flash out of the situation.
Cheers!
-Ray
Hi Emily! I replied to your new post here.
Ray, you've got it!
This discussion is closed. You can start a new discussion or contact Articulate Support.