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

Hi all,

Please help! I've discovered yet another 508-related problem I've discovered. I have invisible buttons over fields in a screenshot that each display a small popup with a brief description. (The learner is invited to select each field to learn more.) I have multiple "clicks outside" triggers to hide the popups and return the buttons back to normal when the learner clicks away from those buttons, which work wonderfully with a mouse, but I'm unable to figure out how to replicate this behavior for a learner who uses a keyboard and screen reader. Such a learner needs to be able to navigate to a button, press Enter to display the popup, "read" the text (e.g. with a screen reader), and then when they press Tab to move focus from the popup, I want the popup to close. Everything up to closing the popup when they move away from it works; it's this last step I'm unable to figure out how to do. Right now, the popup just stays up, and eventually you have a bunch of popups persisting on the page with no way to close them with the keyboard.

I thought maybe Control Loses Focus would do what I want, but it doesn't seem to be designed for that kind of behavior.

I'm aware of the markers, but they create a lot of clutter when placed on top of a screenshot and the result, frankly, is ugly. It would be nice if the popup functionality of markers could be applied to the button functionality.

Another option is mocking up a little close button (X) in the corner, but this is an imperfect and undesirable solution, as it will require me to create even more triggers to display with the popups (because you can't trigger a group, only objects).

Other thoughts on how I can make this work? Is there some magic trigger or setting somewhere that will hide these things again once focus moves from them?

Thanks in advance for the advice.

8 Replies
Lisa Spirko

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!

Tom Kuhlmann
  • 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.

Lisa Spirko

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!


Tom Kuhlmann

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 all has to be managed

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

Tom Kuhlmann

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). 

Lisa Spirko

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!

Maria Costa-Stienstra

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