Our accessibility office has informed me that on quiz slides focus is always placed/stays on the submit button when moving from question to question. This doesn't match up with what happens on non-quiz slides so I'm wondering if anyone else has experienced the same thing.
I'm not sure I understand what you mean by it has the focus? From your accessibility tool? As in that's the first element tabbed to? Typically the tabbing goes from top left to top right although Update 5 did include custom tab order.
The accessibility concern occurred when using the JAWS screen reading software (v16.0.2342) with IE 11 to submit answers to multiple quiz questions.
After submitting a question, when I begin navigating to the question on the next page using JAWS’ Virtual Cursor navigation, the “focus” immediately went to the Submit button. By “focus” I mean that as soon as the next quiz question was visible I pressed the down arrow key (the method of using Virtual Cursor navigation) and the first piece of content announced by JAWS was the submit button at the bottom of the Flash object.
JAWS consistently announces the last item in the Flash object when moving from “slide” to “slide”. However, when tabbing and using JAWS the announced order of elements is correct.
Most users of screen reading software utilize the Virtual Cursor (up and down arrow keys) as their primary means of navigation and only use the Tab key when navigating form controls.
I'll admit I'm not a 508/Jaws expert - although I did see within our documentation in regards to form controls that "Form controls provide full data to assistive technology. The person authoring courses in Storyline can provide instructions and cues to comply with the standard." When you say Form controls are you referring to elements within the slide or the player?
I haven't heard other users mention using the arrow keys as a navigation method unless it's within an element like the Resources tab or similar.
I am Jeani's colleague and I have been performing the accessibility evaluations. Using the arrow keys and not the TAB key is the most common way that users of screen reading software navigate a web page or web application (e.g. Flash) [ref: http://webaim.org/articles/jaws/#reading]. These users also generally navigate content from top to bottom.
In the case of responding to quiz questions, once I submit an answer and move on to the next question, the screen reading software's "focus" stays on this button once the next question appears. So if I continue to navigate down the Flash object, I end up at the end of the Flash object instead of at the top of the new "slide" reading the next question. So I have to navigate backwards through the question to be able to hear the text and the associate answers, make a selection, and submit my answer. This creates extra steps for these users.
The optimum experience would be once I continue to the next question for the "focus" to return to the start of the Flash object so the user only has to navigate once and one direction through the "slide". This is how the "focus" changes when navigating from webpage to webpage using buttons or links. If i navigate to a button in the footer of a page using jaws and activate the button, when the new page loads JAWS will begin reading from the top of the new webpage.
You are correct that the form controls due provide full data to assistive technology. I can access all of the buttons and text, but the order is wrong when navigating with the arrow keys. If I navigate with the TAB key, the order is correct, from top to bottom. The form controls we have been referring to are elements Within the slide NOT within the player.
If you need further clarification, please let me know.
Thanks for reaching out and sharing a bit more information. I checked with a few members of our team, and it sounds like this is a specific set up to how JAWS works - and not an element we can offer support for. Our accessibility support is offered through the tab key - so hopefully if there are others in the community who have dealt with the same set up they'll be able to share here.
You might want to add a suggestion / support case describing the situation. Sounds like there should be some way to support resetting the cursor to the top of the slide when a new slide is loaded.
I know the dev staff worked for quite awhile on the behavior in update 5. If there is a tweak to the behavior that would help most / all screen reader users, I'm sure they'd appreciate hearing how it can be made better.
I wanted to say that Jeani and Joe are not alone here and I hope this issue is addressed.
In testing the accessibility of our new projects authored in SL2 Update 5, we also found that arrow-key navigation does not really work well with Storyline. I understand that the arrow up/down is "a specific set up to how JAWS works," but JAWS is the single most used screen-reader by people who need screen readers. So the fact that JAWS uses arrow navigation is significant; it carries weight. Storyline would be a better tool if the lessons it produced could be navigated as expected using arrow keys.
I'm not an accessibility expert either, but I've been doing as much research as I can and I keep hearing that arrow key navigation is the norm. So I'll submit a feature request and hope for the best.
Joe and Jeani, if you're still subscribed to this thread and you found a particularly good workaround to this Storyline issue, I hope you'll share it here. Thanks!
Thanks for reaching out here and sending along the feature request. As for the navigation, you mentioned you're using Update 5 of Storyline 2 and there was a fix in Update 7 in regards to key press navigation as detailed here. This was in regards to triggers - so I'm not sure if you had set this up as triggers or just were hoping for a built in functionality based on the screen reader.
If Joe and Jeani aren't subscribed you may want to look at reaching out to them specifically using the "contact me" button on their profile.
Jeani and I are still subscribed. This navigation concern still persists when using the arrow keys. However, even when using the Tab key for navigation using JAWS the content may be announced out of order. I have recoreded a screencast video of the issue that I will hopefully attached to this comment. The best suggestion would be to tell the screen reading software users to use the Tab key for navigation since it is more consistent.
Thanks for sharing the video here and letting us take a look. It was hard to follow along as the items were not highlighting on the screen so I couldn't see what was being tabbed to out of order. Did you check that the custom tab order had not been modified?
If you'd like our team to take a look as Steve mentioned, we're also happy to and you can send the .story file along to our team here. You also mentioned JAWS 16 - and I believe the latest update is JAWS 17, and that they only provide support for their latest update, so it may be worth looking into updating as well.
11 Replies
Hi Jeani,
I'm not sure I understand what you mean by it has the focus? From your accessibility tool? As in that's the first element tabbed to? Typically the tabbing goes from top left to top right although Update 5 did include custom tab order.
The accessibility concern occurred when using the JAWS screen reading software (v16.0.2342) with IE 11 to submit answers to multiple quiz questions.
After submitting a question, when I begin navigating to the question on the next page using JAWS’ Virtual Cursor navigation, the “focus” immediately went to the Submit button. By “focus” I mean that as soon as the next quiz question was visible I pressed the down arrow key (the method of using Virtual Cursor navigation) and the first piece of content announced by JAWS was the submit button at the bottom of the Flash object.
JAWS consistently announces the last item in the Flash object when moving from “slide” to “slide”. However, when tabbing and using JAWS the announced order of elements is correct.
Most users of screen reading software utilize the Virtual Cursor (up and down arrow keys) as their primary means of navigation and only use the Tab key when navigating form controls.
For video of the accessibility concern, please see: http://screencast.com/t/qkNVA5K4PoL and http://screencast.com/t/2sAPr5tyxF
Hi Jeani,
I'll admit I'm not a 508/Jaws expert - although I did see within our documentation in regards to form controls that "Form controls provide full data to assistive technology. The person authoring courses in Storyline can provide instructions and cues to comply with the standard." When you say Form controls are you referring to elements within the slide or the player?
I haven't heard other users mention using the arrow keys as a navigation method unless it's within an element like the Resources tab or similar.
Hi Ashley,
I am Jeani's colleague and I have been performing the accessibility evaluations. Using the arrow keys and not the TAB key is the most common way that users of screen reading software navigate a web page or web application (e.g. Flash) [ref: http://webaim.org/articles/jaws/#reading]. These users also generally navigate content from top to bottom.
In the case of responding to quiz questions, once I submit an answer and move on to the next question, the screen reading software's "focus" stays on this button once the next question appears. So if I continue to navigate down the Flash object, I end up at the end of the Flash object instead of at the top of the new "slide" reading the next question. So I have to navigate backwards through the question to be able to hear the text and the associate answers, make a selection, and submit my answer. This creates extra steps for these users.
The optimum experience would be once I continue to the next question for the "focus" to return to the start of the Flash object so the user only has to navigate once and one direction through the "slide". This is how the "focus" changes when navigating from webpage to webpage using buttons or links. If i navigate to a button in the footer of a page using jaws and activate the button, when the new page loads JAWS will begin reading from the top of the new webpage.
You are correct that the form controls due provide full data to assistive technology. I can access all of the buttons and text, but the order is wrong when navigating with the arrow keys. If I navigate with the TAB key, the order is correct, from top to bottom. The form controls we have been referring to are elements Within the slide NOT within the player.
If you need further clarification, please let me know.
Hi Joe,
Thanks for reaching out and sharing a bit more information. I checked with a few members of our team, and it sounds like this is a specific set up to how JAWS works - and not an element we can offer support for. Our accessibility support is offered through the tab key - so hopefully if there are others in the community who have dealt with the same set up they'll be able to share here.
Hey Joe -
You might want to add a suggestion / support case describing the situation. Sounds like there should be some way to support resetting the cursor to the top of the slide when a new slide is loaded.
I know the dev staff worked for quite awhile on the behavior in update 5. If there is a tweak to the behavior that would help most / all screen reader users, I'm sure they'd appreciate hearing how it can be made better.
I wanted to say that Jeani and Joe are not alone here and I hope this issue is addressed.
In testing the accessibility of our new projects authored in SL2 Update 5, we also found that arrow-key navigation does not really work well with Storyline. I understand that the arrow up/down is "a specific set up to how JAWS works," but JAWS is the single most used screen-reader by people who need screen readers. So the fact that JAWS uses arrow navigation is significant; it carries weight. Storyline would be a better tool if the lessons it produced could be navigated as expected using arrow keys.
I'm not an accessibility expert either, but I've been doing as much research as I can and I keep hearing that arrow key navigation is the norm. So I'll submit a feature request and hope for the best.
Joe and Jeani, if you're still subscribed to this thread and you found a particularly good workaround to this Storyline issue, I hope you'll share it here. Thanks!
Hi Belen,
Thanks for reaching out here and sending along the feature request. As for the navigation, you mentioned you're using Update 5 of Storyline 2 and there was a fix in Update 7 in regards to key press navigation as detailed here. This was in regards to triggers - so I'm not sure if you had set this up as triggers or just were hoping for a built in functionality based on the screen reader.
If Joe and Jeani aren't subscribed you may want to look at reaching out to them specifically using the "contact me" button on their profile.
Looks like I'm a couple versions behind, then. Thanks, Ashley!
Hi All,
Jeani and I are still subscribed. This navigation concern still persists when using the arrow keys. However, even when using the Tab key for navigation using JAWS the content may be announced out of order. I have recoreded a screencast video of the issue that I will hopefully attached to this comment. The best suggestion would be to tell the screen reading software users to use the Tab key for navigation since it is more consistent.
Hi Joe,
Thanks for sharing the video here and letting us take a look. It was hard to follow along as the items were not highlighting on the screen so I couldn't see what was being tabbed to out of order. Did you check that the custom tab order had not been modified?
If you'd like our team to take a look as Steve mentioned, we're also happy to and you can send the .story file along to our team here. You also mentioned JAWS 16 - and I believe the latest update is JAWS 17, and that they only provide support for their latest update, so it may be worth looking into updating as well.
This discussion is closed. You can start a new discussion or contact Articulate Support.