Best practices for making accessible select to reveal interactions.
Sep 16, 2022
Accessibility is mandatory for the majority of the projects I build in Storyline. There are multiple ways to build interactions where a user must select a series of elements on screen to reveal additional content. The challenges of meeting the various types of accessibility requirements (for example, keyboard navigation with no screen reader for motor impaired users vs keyboard navigation with screen reader for visually impaired users) prompted me to try out various solutions. Which of the following would be considered "best practices" within the constraints of Storyline's tool set?
- Layer based - selecting an element shows a layer containing the additional content. I have found that the focus order can get confusing to users navigating among multiple layers.
- State based - selecting an element shows a previously "hidden" element containing the additional content. In a previous version of SL, elements that started in the default "Hidden" state were not accessible to screen readers even if they later were set to a "Normal" state. As a work around we had to have the text in the revealed element's "normal" state set to match the background color of the element and change the text color to something visible in the "visited" state. I am not sure if this issue has been fixed.
- Alt-text based - There is also the option to add Alt text directly to the selectable element so that it contains the additional content by itself. So as soon as a user with a screen reader focuses on the element, they would get the full content read to them without having to press <Enter>. The revealed element would not be part of the accessible focus order because it would just duplicate what is already in the selectable element's alt text.
3 Replies
Hi Randall,
Thanks for reaching out!
You can check out this article contains our tips and best practices on how to design accessible courses in Storyline 360:
While I can't say for certain which of the three options is best, we hope the article helps point you in the right direction!
I would go with layer based or state based and perhaps a combination of alt text based.
Layers are probably the easiest as long as you get the focus order correct, think it through in a logical order helps.
Hidden state is not visible to a screen reader, but would be when turned to any other state, again getting the focus order correct will help so that the object that changes it to normal is before the object that changes from hidden.
Each state can have individual alt text.
I often use alt text to give additional information to the user that would benefit from it if they are using a screen reader, although have never used it how you describe, I think it may be confusing as if there is a trigger attached the object will be called out as a button. The first two options you describe would be my goto, and I would use elements of the third but sparingly.
Thanks for the feedback, Phil.
Your comment about the states having individual alt text got me thinking.
Could you have a single "reveal-able" element with multiple states that get displayed. Does the Focus Order dialog allow you to focus on an element multiple times?
For example:
User tabs to and selects button 1 - reveal item state 1 is shown - tabbing focuses onto reveal item
User tabs to and selects button 2 - reveal item state 2 is shown - tabbing focuses BACK onto this reveal item with the new state
I may have to experiment with this. Unfortunately I don't think using this approach would work well if you can't include the reveal-able multiple times as the user would have to tab through all the buttons to get to each "reveal"
I only have NVDA installed, so I would be curious how JAWS handles this sort of thing.