Trigger to close an object when tab focus moves from it?

Can you show us what you want to do using a Peek video or demo of the course?

Hi Tom. Thank you so much for your reply. Although I can't share my course, because it has proprietary information, I put together a simplified example in the attached file.

I managed to discover that you can program anything to hide upon a key press. The Enter key works now for closing the popups, but the Tab key does not work in the same way. (The file contains a detailed description of what's wrong, and why I think I have discovered a bug.) 

Although the Enter key works pretty well, I would prefer the Tab key for a couple of reasons. (1) It would require only one keystroke to simultaneously close the popup and move tab focus to the next button, and (2) it would not lose the yellow tab focus box. By comparison, the Enter key requires two keystrokes: Enter to close the popup (which makes the yellow box disappear--potentially disorienting), and then Tab to move the tab focus to the next button.

Thank you so much for your help!

• When you tab to button 3 and click, you open the pop up 3. Then it requires a tab to get to pop up 3. However, there's a trigger to close pop up 3 when tabbed.
• Thus you're tabbing to it and triggering it to close, as well.

I'll check with support to see what they say about the expected behavior and what should be in focus and when.

A different consideration:  generally tabbing is a way to navigate the content. By adding a trigger to create an additional action it is a bit non-standard and may be confusing for the person who is using a screen reader to access the content. I don't think adding the extra click is an issue for a person used to using the readers.

Are you able to get some feedback from someone who uses a screen reader? It would be interesting to get their perspective. 

I'd design the interaction a different way: perhaps use layers that the person can open and close. Or add a hidden button for the reader that lets them open a layer optimized to get the content. Then the screen can be more scannable and easier to parse.

Hi Tom, thank you for your response. Can you explain the hidden button idea further? I'm not sure what you mean by a layer that is optimized to get the content.

A couple of thoughts on the rest of your reply:

-- I understand your point about tabbing as a way to navigate the content. I'm just not sure that the tab trigger and the enter button trigger are behaving in a similar manner (which they should be). For the first two popups, the Enter trigger is not activated until the popup is already in focus (has the yellow box on it), which is what I expected, while on the last two popups, the Tab trigger is activated while the focus is still on the button and never gets to the popup.  

-- We don't know of any learners who use screen readers, so unfortunately, we're flying blind here.

-- I had considered using a layer for each popup, but quickly nixed the idea because in reality, the version of this slide in my course is much more complicated. It's a slide with audience-specific screenshots. (The version of the application screen has extra fields and in different layouts compared to the other audience's version.) So, I have the screenshot, buttons, and popups for one audience on one layer, and those items on a second layer for the other audience. The correct layer displays based on a variable set at the beginning of the course. If I did as you suggest, I would have about 18 layers. It would be complicated mess to manage. If I ever have to do popups like this again and there are no audience-specific considerations, layers would likely be the best option.

Please let me know what you find out about that tab trigger behavior.

Thank you again for your help. It's much appreciated!

Lisa

Hidden button:

Many people create a hidden button that's not seen visually, but that the person using a screen reader gets at the beginning. It gives them an option to get the content in a different way. For example, it may be an alternate slide or layer that is optimized for the screen reader.

Personally, I wouldn't use tabbing to access and then close the content. It's not how navigation works and if they shift-tab it doesn't work at all.

18 layers or 18 triggers or 18 states...it all has to be managed

I think the layers is the cleaner option, but that's a matter of personal preference.

Support looked at the tabbing and documented it as a HTML5 bug. It works in Flash as designed.

A work around is to use the enter key to trigger the close rather than tab. This is also more in line with expected navigation. Although, you need to inform the person to press enter to close. The more conventional option is to have a specific close trigger (like a button). 

Thanks for looking into this and letting me know, Tom.

Yeah, I ended up programming it with the Enter key and have included an instruction about it on our keyboard instructions lightbox page. I considered adding a close button or X icon, but felt that would clutter up the trigger list and tab order list too much (resulting in about 36 items instead of 18). Many thanks again for your help and advice!

Hi, Lisa.

I just wanted to share that we no longer see the bug reported where Using Tab Keypress trigger to change object's state fires before focus is on the object using the latest build of Storyline (3.61.27106.0).

If you're using the latest version and you're still experiencing this issue, please reach out to our support team through a case.