I'm having an issue while trying to make a course accessible. Every time a layer is shown or hidden, the tab order starts from the top once again. In practice, if I have a button that shows a popup, the user will have to tab all the way to the popup again from the start. This can be half mitigated by putting all popup layers at the very top of the tab order, but once the popup is closed, the user will have to tab through the whole slide once again.
Attached is a small story file example that demonstrates my issue.
I am on version 3.18.16449.0
I have tried both in preview and publishing, on Firefox and IE, and on SCORM LMS.
How odd. I filed a report, Case #02323169, so hopefully that helps you track down those files, in additions to the ones I've posted earlier in this thread which also exhibit this behavior.
Ah, not so odd after all Douglas. I appreciate you sharing your support case number. I was able to see the case where you are working with Robert. It looks like you have a couple of e-mails and that's how I missed it. Thanks for making the connection for me.
I was informed by Articulate staff that SL360 version 3.44 and its Focus Order enhancement might fix the issue I was describing of screen reader focus going to an unpredictable spot when a layer is closed, so I wanted to chime in with my initial findings.
Unfortunately, the issue does not appear to have been addressed; I'm still experiencing what I described previously with NVDA, JAWS 2018 and JAWS 2020. JAWS 2020 offers the "best" user experience in that focus always goes back to the slide start, and while that's far from ideal, at least its predictable and consistent; unfortunately though, very few individuals within our user community have JAWS 2020 (NVDA is, by far, the most commonly used screen reader).
I'm also noticing that NVDA is calling some non-interactive elements "clickable" and that JAWS 2020 seems to be reading what I think is the default alt text for an image that was added through Background Styles in Slide Master, but I'm not sure if these are new to this version. That NVDA behavior seems familiar and I don't think I've previously tested, with JAWS 2020, a SL360 course that had an image added that way.
Unfortunately I am experiencing this issue as well. When testing for screen reader, we use JAWS and our recommended browser is Chrome.
This doesn't happen all of the time, but it does happen most of the time.
Essentially what is happening is when a button is clicked, and that button either disappears or becomes disabled (this includes the layer the button is on hides), the focus goes back to the beginning of the focus order.
I am using the current JAWS, Chrome and Storyline.
I apologize for the issues you are experiencing with the focus order reverting to the beginning when using JAWS sometimes in Storyline.
Are you working from the latest version of Storyline? The current is Build 3.63.27674.0.
It would be helpful if we could take a look at your project file by opening a case with one of our support engineers. We will delete it from our systems when troubleshooting is complete.
I'm seeing this issue too. This is a fairly recent issue that is breaking the accessibility for screen readers. We used to be able to use layers and order them in the focus order like this:
Base: Button 01 (opens layer 01)
Layer 01 (close layer 01, and use down arrow to get to the next element, Button 02).
Base: Button 02
Layer 02
We were able to order the focus order as such, and the screen reader would return to the next element in the order, but now, as the post above says, more often than not, the screen reader is directed to the top of the slide and the user must navigate through the slide contents again to get to the next element in the focus order.
Is this something the engineers are aware of and working on? SL courses aren't going to pass accessibility testing using the method I've outlined above.
I was actually doing some testing of Focus Order and layers today in the most recent version, and here’s what I found…
Testing conditions: NVDA+Chrome; layers where shown via objects (shapes in one test, pictures in another, same results with both) that had ‘show layer when user clicks’ triggers; layers contained objects with ‘hide this layer when user clicks’ triggers.
If the layer had the ‘Prevent users from clicking on other layers’ layer property assigned: when you opened the layer, focus would go to the element in the layer that was highest in the Focus Order—same behavior I’ve encountered for a long time. But, when you hid the layer, focus would go back to the object used to open the layer in the first place—different than previously experienced behavior, where focus would land on whatever detectable object came next in the Focus Order (ie, whatever was after the object that had the ‘hide layer when user clicks’ trigger).
If the layer did not have the Prevent… property assigned, when you opened the layer, focus would stay on the object with the show layer trigger—same behavior as experienced for some time. And when I closed the layer, focus would go to a random spot in the Focus Order, but for me, always one after the object with the hide layer trigger, so more toward the end of the slide’s Focus Order and not toward the top as others reported—this has been my experience for years.
And actually, the whole reason I did this testing was that I was finding other Focus Order irregularities: objects being skipped; differences reading backwards compared to forwards. I didn’t end up finding a consistent rule or pattern I can share, unfortunately.
I think some solid testing needs to be done on this area. I've just switched some layers to "prevent" and they are behaving better, i.e, focus returning to the button that triggered the layer.
I have some really bizarre results though where slides using identical set-up have different results. I need to look further in to those slides and see what the differences are.
Other things I've seen having an impact are Heading on layers (good impact) and animation (bad impact). Key elements need to be at the start of the timeline in the layer in order to ensure they are picked up by the screen reader.
It would be good for Articulate to focus on this issue as it's a significant one in my opinion, or provide the best practice development method.
We're running into these issues quite a bit now too. The worst part is that it's the same as Sam Hill's above where identical slides are behaving differently. Much like others though, there can be some benefit/workaround by using 'prevent' but this in turn blocks using shared navigation on the base layer - which creates a LOT of extra / duplicate development work for something that should just do what it's supposed to.
For what it's worth, I've spent the past week updating a project from SL3 to SL360, and when testing it, I've been experiencing slightly better behavior in regards to this issue: that is, when closing layers that do not have the "Prevent users from clicking on other layers" property applied, I've had my focus land where I'd want/expect within the base layer a surprising amount of times. It's still far from perfect -- I don't think I'm getting the desired behavior even 50% of the time -- but it's better than finding this issue in every single slide.
Unfortunately, I cannot explain these better findings or connect them to a recommendation. I hesitate to say it's thanks to having a newer version of SL360; I'm using v3.66.28270 now but might've been using that version in the testing mentioned in my 7/20/22 post, and I'm not seeing anything related to this is the v3.66.28270 version history. I doubt it's because I was converting an old project, since usually I encounter more issues, not fewer, with pre-SL360 projects.
Thanks for the update Douglas - our experience is also typically less than 50% success, in 360 as well and we pickup the updates as soon as they come out. The only way we've found any consistency whatsoever is via the 'prevent' method, but as also mentioned this comes at the cost of duplicating all navigation on every layer and this is a significant undertaking on some interactions (consider a slide with 10 buttons or vertical tabs or accordion interactions with variables for interaction locking/tracking) this quickly gets messy.
Has this been resolved yet? We're considering adding Articulate as one of our tools, but there are a lot of accessibility issues. I'm experiencing the same issue where when you close a layer, the focus goes back to the top of the base layer, this is SL360 v3.71.29339.0
The bug discussed in this has already been fixed by a previous update, so there's a chance that the behavior you are experiencing is something different. The latest version of Storyline 360 is Update 80so the one you're currently on is already a bit outdated. Would you mind updating to the latest version of Storyline 360 to see if this helps? Here's how.
If the issue persists, would you be willing to share a copy of your project file here or in private by opening a support case so we can verify if you are being affected by a bug? We'll delete it when we're done testing!
39 Replies
Hi Leslie,
How odd. I filed a report, Case #02323169, so hopefully that helps you track down those files, in additions to the ones I've posted earlier in this thread which also exhibit this behavior.
Thanks,
Doug
Ah, not so odd after all Douglas. I appreciate you sharing your support case number. I was able to see the case where you are working with Robert. It looks like you have a couple of e-mails and that's how I missed it. Thanks for making the connection for me.
I was informed by Articulate staff that SL360 version 3.44 and its Focus Order enhancement might fix the issue I was describing of screen reader focus going to an unpredictable spot when a layer is closed, so I wanted to chime in with my initial findings.
Unfortunately, the issue does not appear to have been addressed; I'm still experiencing what I described previously with NVDA, JAWS 2018 and JAWS 2020. JAWS 2020 offers the "best" user experience in that focus always goes back to the slide start, and while that's far from ideal, at least its predictable and consistent; unfortunately though, very few individuals within our user community have JAWS 2020 (NVDA is, by far, the most commonly used screen reader).
I'm also noticing that NVDA is calling some non-interactive elements "clickable" and that JAWS 2020 seems to be reading what I think is the default alt text for an image that was added through Background Styles in Slide Master, but I'm not sure if these are new to this version. That NVDA behavior seems familiar and I don't think I've previously tested, with JAWS 2020, a SL360 course that had an image added that way.
Hello Douglas and Jason,
Great news! We just released another update for Articulate 360 and included a few important fixes you'll see in the release notes.
The item you'll be interested in is:
Fixed: When using a screen reader, the focus order didn't always follow the correct path for slides with layers.
Just launch the Articulate 360 desktop app on your computer and click the Update button for Storyline 360. Details here.
Please let us know if you have any questions, either here or by reaching out to our Support Engineers directly.
Unfortunately I am experiencing this issue as well. When testing for screen reader, we use JAWS and our recommended browser is Chrome.
This doesn't happen all of the time, but it does happen most of the time.
Essentially what is happening is when a button is clicked, and that button either disappears or becomes disabled (this includes the layer the button is on hides), the focus goes back to the beginning of the focus order.
I am using the current JAWS, Chrome and Storyline.
Please let me know the status of this issue.
Hi Steven!
I apologize for the issues you are experiencing with the focus order reverting to the beginning when using JAWS sometimes in Storyline.
Are you working from the latest version of Storyline? The current is Build 3.63.27674.0.
It would be helpful if we could take a look at your project file by opening a case with one of our support engineers. We will delete it from our systems when troubleshooting is complete.
I'm seeing this issue too. This is a fairly recent issue that is breaking the accessibility for screen readers. We used to be able to use layers and order them in the focus order like this:
We were able to order the focus order as such, and the screen reader would return to the next element in the order, but now, as the post above says, more often than not, the screen reader is directed to the top of the slide and the user must navigate through the slide contents again to get to the next element in the focus order.
Is this something the engineers are aware of and working on? SL courses aren't going to pass accessibility testing using the method I've outlined above.
Thanks all.
I was actually doing some testing of Focus Order and layers today in the most recent version, and here’s what I found…
Testing conditions: NVDA+Chrome; layers where shown via objects (shapes in one test, pictures in another, same results with both) that had ‘show layer when user clicks’ triggers; layers contained objects with ‘hide this layer when user clicks’ triggers.
If the layer had the ‘Prevent users from clicking on other layers’ layer property assigned: when you opened the layer, focus would go to the element in the layer that was highest in the Focus Order—same behavior I’ve encountered for a long time. But, when you hid the layer, focus would go back to the object used to open the layer in the first place—different than previously experienced behavior, where focus would land on whatever detectable object came next in the Focus Order (ie, whatever was after the object that had the ‘hide layer when user clicks’ trigger).
If the layer did not have the Prevent… property assigned, when you opened the layer, focus would stay on the object with the show layer trigger—same behavior as experienced for some time. And when I closed the layer, focus would go to a random spot in the Focus Order, but for me, always one after the object with the hide layer trigger, so more toward the end of the slide’s Focus Order and not toward the top as others reported—this has been my experience for years.
And actually, the whole reason I did this testing was that I was finding other Focus Order irregularities: objects being skipped; differences reading backwards compared to forwards. I didn’t end up finding a consistent rule or pattern I can share, unfortunately.
I think some solid testing needs to be done on this area. I've just switched some layers to "prevent" and they are behaving better, i.e, focus returning to the button that triggered the layer.
I have some really bizarre results though where slides using identical set-up have different results. I need to look further in to those slides and see what the differences are.
Other things I've seen having an impact are Heading on layers (good impact) and animation (bad impact). Key elements need to be at the start of the timeline in the layer in order to ensure they are picked up by the screen reader.
It would be good for Articulate to focus on this issue as it's a significant one in my opinion, or provide the best practice development method.
We're running into these issues quite a bit now too. The worst part is that it's the same as Sam Hill's above where identical slides are behaving differently. Much like others though, there can be some benefit/workaround by using 'prevent' but this in turn blocks using shared navigation on the base layer - which creates a LOT of extra / duplicate development work for something that should just do what it's supposed to.
For what it's worth, I've spent the past week updating a project from SL3 to SL360, and when testing it, I've been experiencing slightly better behavior in regards to this issue: that is, when closing layers that do not have the "Prevent users from clicking on other layers" property applied, I've had my focus land where I'd want/expect within the base layer a surprising amount of times. It's still far from perfect -- I don't think I'm getting the desired behavior even 50% of the time -- but it's better than finding this issue in every single slide.
Unfortunately, I cannot explain these better findings or connect them to a recommendation. I hesitate to say it's thanks to having a newer version of SL360; I'm using v3.66.28270 now but might've been using that version in the testing mentioned in my 7/20/22 post, and I'm not seeing anything related to this is the v3.66.28270 version history. I doubt it's because I was converting an old project, since usually I encounter more issues, not fewer, with pre-SL360 projects.
Thanks for the update Douglas - our experience is also typically less than 50% success, in 360 as well and we pickup the updates as soon as they come out. The only way we've found any consistency whatsoever is via the 'prevent' method, but as also mentioned this comes at the cost of duplicating all navigation on every layer and this is a significant undertaking on some interactions (consider a slide with 10 buttons or vertical tabs or accordion interactions with variables for interaction locking/tracking) this quickly gets messy.
This post was removed by the author
Has this been resolved yet? We're considering adding Articulate as one of our tools, but there are a lot of accessibility issues. I'm experiencing the same issue where when you close a layer, the focus goes back to the top of the base layer, this is SL360 v3.71.29339.0
Hello Janis,
Sorry to hear that you ran into this snag.
The bug discussed in this has already been fixed by a previous update, so there's a chance that the behavior you are experiencing is something different. The latest version of Storyline 360 is Update 80 so the one you're currently on is already a bit outdated. Would you mind updating to the latest version of Storyline 360 to see if this helps? Here's how.
If the issue persists, would you be willing to share a copy of your project file here or in private by opening a support case so we can verify if you are being affected by a bug? We'll delete it when we're done testing!