Hotspots not accessible via keyboard or screen reader

Hi there, 

I read that Storyline 2 is supposed to be fully compliant with Accessibility guidelines, so I was surprised to discover that it has actually lost functionality that was present in Storyline 1!

Keyboard navigation no longer works on hotspots.

Similarly, screen readers no longer read out hotspot alt text. 

Please refer to published file here: https://dl.dropboxusercontent.com/u/101820917/troubleshooting/storyline-hotspots/story.html

Attached is the story file used to create this file. 

These issues mean that Storyline does not allow full keyboard navigation, meaning that it is not compliant with accessibility guidelines. 

I will log this as a support ticket, but was wondering if anyone had stumbled on this issue?

9 Replies
Kuriko A

Thanks Matthew. I did not find this page in my search for 'storyline', 'accessiility' and 'hotspots' so thanks for pointing it out. It seems to contradict the claim of 'Full keyboard navigation' that is stated on this page. So I wonder if the Articulate team are planning to update this claim on this page, so that it accurately reflects the capability of Storyline 2 and so that it doesn't confuse more users. Especially since people upgrading from Storyline 1 will expect the same functionality as was available in Storyline 1. 

Ashley Terwilliger-Pollard

Hi Kuriko,

Full keyboard navigation refers to navigating between slides or player elements using the arrow keys, space bar and enter key. Accessing elements on the slide such as a hotspot is not included in the navigation element.

Also, if you connect to the Storyline 1 508 guidelines here you'll see the same reference in regards to hotspots and drag and drops being an exception. 

Kuriko A

Hi Ashley,

Thanks for your response. This is so surprising since this functionality was present in storyline 1 and we relied on it heavily to create accessible courses.

I note the workaround of using transparent shapes instead of hotspots, however this is a nuisance as you can't easily identify them on screen during development since they are transparent. This means it's not as easy to manipulate/modify them as required.

I know your next step is to suggest I submit a feature request, but I honestly think it's ridiculous to have to request a feature that was already present before I 'upgraded' to storyline 2... Is there any explanation at all as to why this functionality was lost during the development of storyline 2? I thought that accessibility was meant to be a priority in the development of storyline 2?

Ashley Terwilliger-Pollard

Hi Kuriko,

I'm not sure I'm clear on how you had this before in Storyline 1, as hotspots were not accessible in Storyline 1 either per the linked documentation.  Here's the line I'm referring to within the Storyline 508 guidelines:

You can execute most Storyline functions using a keyboard. Exceptions include drag-and-drop and hotspot interactions.

So I can't say that it was lost or changed at all in Storyline 2. 

Kuriko A

Hi Ashley, 

Well... I waited to see if you might actually test this issue after falsely claiming that "hotspots were not accessible in Storyline 1". But since you haven't, I went ahead and replicated my file in Storyline 1. Please watch the 60 second video linked below in which you can clearly see that hotspots ARE accessible in Storyline 1 – both via keyboard and screen reader – and ARE NOT accessible in Storyline 2. 

Watch video here: https://dl.dropboxusercontent.com/u/101820917/troubleshooting/storyline-hotspots-video/index.html

The Storyline 1 file has been published, zipped and attached. Likewise, the story file is attached for your reference. 

In future, it would be greatly appreciated if the Articulate team could dignify users' bug reports by actually testing them first before responding. 

The users on this forum are the people who are willing to take time out of their day to provide your team with feedback (sometimes about errors like these which really should have been picked up in your own internal QA processes). Keep in mind that most users of your product will simply find these bugs, lose interest in the software, not report the issue and just tell all their colleagues that they'll never use it again! We, however, are the people who are committed to trying (...and trying ....and trying) to improve this product for the benefit of the broader user community. So I ask that you please respect the time we are dedicating to this cause, by not disregarding our comments and feedback. 

Thank you. 

Ashley Terwilliger-Pollard

Hi Kuriko, 

First off I wanted to apologize for my misunderstanding of how you were defining accessibility and not following this through as you expected.

To clarify a bit further, I appreciate you sharing the video and the sample files and the hotspots as they are currently designed in Storyline 1 and Storyline 2 did not meet our definition of 508 accessibility as they are intended to be used with a mouse. Within Storyline 1 as you demonstrated you could tab to them, and after a bit more digging I was able to find that this was reported to our team as a bug because users could tab through a hotspot question to find the correct answer, thereby cheating the system. Based on this issue, we changed how hotspots worked in Storyline 2, since we heard from users and determined that most course authors don't want their learners to be able to find the location of a hotspot on the screen with the tab/keyboard functionality but would prefer the user is clicking where they think it may exist. 

The documentation I shared in regards to the elements of Storyline 1 and 2 that are not designed for 508 accessibility still hold true in that hotspots and drag and drops aren't accessible through keyboard triggers. The same fix was also applied in Studio '13 (Quizmaker) as users could previously tab to the hotspot. 

Again, I want to apologize if you felt disrespected by my answer, as it was certainly not my intent. Since I knew it was something that shouldn't work in Storyline 1 or Storyline 2 per our documentation, I felt confident in that answer and the set up of how it's currently set to work in Storyline 2 being expected and designed behavior on our end. We certainly value our community members opinions, ideas and assistance in tracking down issues and pass threads such as these along to our Product team and Quality Assurance when warranted. 

I hope that helps clarify the change in behavior and how I shared it here, but if you have any other questions about this issue please feel free to let me know. 

Kuriko A

Thanks for your apology, Ashley. 

I understand your explanation, and I'm not surprised to hear that the misunderstanding was caused by the fact that Storyline 1's 'accessible hotspots' were actually another unresolved bug in the software. Since this functionality has always been present in the software, my team assumed it was intended functionality, which is why we came to rely on them! And whilst we don't use the software for 'find the object' types of interactions, I can certainly see how this might be a really annoying bug for people that do. 

The reason why we actually started using them was because we discovered yet another bug whereby once you create a button (shape or picture) and add states to it, screen readers will not identify the Alt text that you enter after that. Therefore, in order for Alt text to be read correctly by screen readers, you need to first add the Alt text to the shape/picture, then add states. Doing it in the opposite order fails to work. This makes it impossible to duplicate buttons and means that you need to create each button individually from scratch each time you use it. As you can appreciate, this is a ridiculous waste of time, which is why we solved the issue by using hotspots over our existing buttons, so that we can copy and paste our buttons and customise the Alt text at any time. We never bothered to report this bug because we had found a reasonable workaround. (Storyline users are VERY good at finding workarounds for all the unresolved bugs!)

Anyway, since the 'accessible hotspots' are actually a bug, it's quite alarming that it still hasn't been resolved in the current release. It looks like this one has been waiting on Articulate's 'Bug fixing to-do list' for 4 years now! (No wonder we thought it was just 'part of the package'!) 

I'm pleased to hear that *in theory* the Articulate team values community members' assistance in identifying issues with its products. However, actions speak louder than words.... and the long list of unresolved bugs in Storyline 1 and 2 just go to show that this statement is not actually evident in the company's practice. 

As I mentioned in another thread, I understand that with software, there are often a few small bugs to iron out after its initial release, when end users pick up on a few issues that should have been identified and addressed in the internal QA process prior to release. This happens, and users are pretty understanding of this within the first 6 months.

Sometimes, in the instance of open source software, these bugs can go unaddressed for a year or longer as nobody is being paid to maintain the code. However, Storyline is a product which has a long string of bugs found by users (or shall we call them the volunteer QA team?) which have been raised in this forum, logged as a support ticket and then left to 'collect dust' for years on end (e.g. this one and this one). This is totally unacceptable, because unlike open source software, the Articulate developers ARE getting paid and Articulate charges a significant fee for their product.

My suggestions to the company would be to:
1) employ some additional, highly skilled people to join your QA team to identify these bugs during the development process
2) employ more developers to systematically work through the long list of bugs identified by users of your software.

If the company's reason for not doing this is because their revenue is not high enough to afford this, I would say that if they actually invested in fixing these bugs, they would have a whole army of advertisers on this forum, shouting about how great a product Storyline is! Instead, their inattentiveness to the reported issues has turned these potential advocates into people who are now bitterly dismayed with their purchase of Storyline. This inattentiveness is also likely to be negatively affecting potential users/customers who read the threads in this forum. Who would blame them from opting to use another product, when they see that most threads here end with an Articulate rep saying 'log a support ticket', only to never have a solution – even up to four years later!).

Reputable software companies, when alerted to bugs in their software, ensure that they are fixed before releasing the subsequent update. However, this is not the case with Articulate. If the Articulate team is actually dedicating their time now to developing Storyline 3, rather than fixing unaddressed issues in Storyline 1 and 2, this is ludicrous. Users shouldn't have to pay for a new product because the previous one they bought from the company was faulty (not to mention that the next 'upgrade' will no doubt have a whole list of new bugs for us to identify, which will also likely never be fixed).

It is Articulate's responsibility to maintain the products which they've already sold to us, and ensure that they work as expected. Unfortunately, it seems that Articulate is only interested in 'wowing' and 'luring' in new customers, but is not too concerned with retaining existing customers.

Nonetheless, I appreciate your sentiment that you value customer feedback. Unfortunately, the responsiveness of the team behind you points to quite the opposite.

Ashley Terwilliger-Pollard

Hi Kuriko,

I wanted to let you know that I've also shared this thread with our product manager, Brian, who also is aware of the other thread that you linked to. 

I know my words may not mean as much, but please know that I have passed this forum thread along to the appropriate individuals and teams so that we can continue to discuss and work on the issue. Thanks for keeping us honest and continuing to share candid feedback.