Accessibility issue - keyboard focus ignoring buttons on layers
Sep 30, 2014
To comply with Accessibility requirements, I've been testing whether my course is fully functional when using only a keyboard. Unfortunately, I've found that it is not.
On most slides, the keyboard focus works great using the TAB key to move the focus and the ENTER key to make selections. If I'm on a base layer of a slide which has on-screen buttons, and I use the TAB key to move the keyboard focus (the yellow square) between the available on-screen buttons, this works fine. I can tab through to the last available button at the bottom of the screen, then, if I TAB again, it returns to the first available on-screen button again at the top of the slide and moves through the buttons all over again. This is the expected behaviour.
However, if I am on a slide layer (not the base layer) which has on-screen buttons, the keyboard focus moves between the available on-screen buttons until it gets to the last button on the screen. But, if I click the TAB button again, expecting it to focus again at the first available on-screen button and start again, it does not. Instead, it focuses on the Storyline player buttons only - ignoring all of the on-screen buttons - and then loops continuously...
For a user who can only access the course via a screen reader, I imagine this would be even more frustrating, as the computer keeps repeating: MENU TAB - NOTES TAB - MENU TAB - NOTES TAB - MENU TAB - NOTES TAB etc, when all they want to do is access the on-screen buttons that the course is telling them to click! I believe this issue is very concerning, as users with a disability should be given the same access to the course as users who are able to use a mouse and/or able to hear the narration without a screen reader.
I've submitted this case to the Storyline Support team and they've been able to replicate this, but do not have a workaround at this stage. They have reported it to the QA Team to look into further.
In the meantime, I was wondering if anyone else out there had encountered this issue, and if so, if you have worked out a way to avoid this from happening?
11 Replies
Hello Kuriko!
I do see the support case you submitted, and that they have sent the information to the QA team for review.
You could in the meantime take a look at this thread to see if it may give you some information.
And some other members may be able to chime in as well.
Hi Emily,
Thanks for your reply. I already checked out that thread. It's related to a different issue and was unresolved anyway, ending with a feature request for custom keyboard focus order to be introduced into Storyline (which I, too, would like to +1!)
I'll wait to see if anyone else stumbles on my post whilst trying to create a course which is fully accessible to learners with a disability.
Hello Kuriko!
You can submit the feature request here. And hopefully others will get involved with this post as well.
Hi Kuriko
Did you submit a feature request for this? I have the same problem and it is a major issue for me. Along with the Tab order issue.
Hi Vicky,
I'm not sure that Kuriko is still subscribed, but you could send in a feature request as well - the more the better!
Hi there,
I submitted this as a bug to the QA team. I didn't submit it as a feature request, as it is a software bug not a feature request, and should therefore be given higher priority than feature requests.
Having said that, it has been 8 months since I heard back on the case from Jonathan Reque, Customer Support Engineer. The case number was: #00423811: *PMP*
Ashley and Emily, if you could please follow up on this case for us with the QA team, that would be great. Thank you.
Hi Kuriko -
The recent Storyline update, release 5, focused heavily on improving accessibility function in the player. Did you have a chance to test the original issue in the new version to see if the problem remains?
Hi Steve,
I've tested it with the latest version of Storyline 1 – Update 8 – and tried republishing it, but it still doesn't work.
I already submitted a detailed screen capture and a sample story file (which I'm not at liberty to share publicly) in my support ticket. Jonathan Reque replied to my ticket: "We were able to duplicate the issue but unfortunately, we were unable to determine a workaround. We have reported this issue to our Quality Assurance team for their review. I cannot offer a time frame for when this issue will be addressed... I will email you also if this gets fixed in the future."
I have not heard any updates since.
I then upgraded the file to Storyline 2 – Update 5 – and tried republishing It and the issue seems to have been fixed in Storyline 2, but not in Storyline 1.
Obviously, I can see that the long term plan is to have all users switch to using Storyline 2. But Storyline 2 still has a number of bugs to be ironed out and so I (and probably many other users) am still switching between both versions for different purposes.
Therefore, it would be great if the Articulate team could advise if/when this issue will be fixed in Storyline 1.
Hi Kuriko,
The custom tab/focus order was a feature request in Storyline 1, and then included as a new feature in the most recent update of Storyline 2. As for the issues you've discussed with Jonathan, I do see that they were reported to our QA team for additional review, but we're unable to offer a time frame in regards to when/if the items will be fixed in a particular version or update.
Hi Ashley,
Just to be clear, the 'custom tab/focus order' feature request is a separate issue entirely to this bug. However, it appears that improvements that have been made to accessibility in Storyline 2 have (inadvertently perhaps?) fixed this bug in question.
Should we therefore assume that bugs in Storyline 1 are not being given priority, compared with bugs in Storyline 2?
I've heard this line many times before: "we're unable to offer a time frame in regards to when/if the items will be fixed". Based on the fact that I took the time to test these issues, submit sample files, prove the bugs and report them, only to be waiting 8 months and still receive no update, it is not very encouraging for myself and other users that it is worth our time in testing and reporting bugs.
I assumed that the QA team would make it an urgent priority to ensure that the software is bug-free and accessibility-compliant – before implementing improvements and feature requests – but based on the 8 month timeframe on this issue with still no resolution, its clear this is not the case.
Hi Kuriko,
Storyline 2 did include a number of new features and fixes related to accessibility, and the bug element that you report to our Support team did not appear in Storyline 2, although the issue is still with our team for Storyline 1.
As for that issue, I can't speak to the timeframe or progress as I mentioned, but please know that our QA team does take these reports seriously and investigates them.
This discussion is closed. You can start a new discussion or contact Articulate Support.