Forum Discussion
Rethinking Storyline's Accessibility Checker Guidance on Accessible Video Controls and Autoplay
Storyline’s new accessibility checker is a very useful tool and can be leveraged to create more accessible courses. However, the guidance on disabling autoplay and turning on accessible video controls appears misguided. The following course passes the accessibility checker but has two playback controls that are not synced together. Please visit the Inaccessible Course Example. This design would not be very usable or accessible.
For context, the courses I am working on include transcripts in each course's notes section. Can someone show me an example where the accessible video controls feature is implemented successfully? Is there a way to avoid duplicate player controls?
Why can’t the transcript feature be included in the main Storyline player?
Including the transcript feature could alleviate the need for accessible player controls and improve the learning experience. Also, it would be great if the AI workflow could create captions and add a transcript automatically. This would be a significant time saver. The accessibility checker should prompt the author to check the captions and transcript to ensure they are accurate as well.
Another issue is the autoplay setting. The accessibility checker makes it seem straightforward to turn off autoplay. The author needs to set the option “Play video” to when “clicked” or “triggered.” Unfortunately, this change causes the Storyline Player to not control or stay in sync with the video.
Implementing autoplay globally across a course appears to be much more complex. The University of California’s Office of the President has an article called, Avoiding Autoplayed Media. This article goes into the technical steps required to configure autoplay for a slide or a course in Storyline. It does not reference the “Play video” toggle. Instead, the author must leverage triggers and variables in the project to stop slides from autoplaying globally.
In this example, I configured a trigger to stop the video when the rectangle appears on the slide. I configured another trigger to start the video when the rectangle leaves the slide. I also used guidance from How to Pause and Sync Videos with Timeline in Storyline 360. This is because by default, Storyline enables “Pause on click.” However, the video can get out of sync with the timeline if clicking on the video pauses it. This technique creates a variable to track when a user clicks the video to ensure it stays in sync with the Storyline player. This technique is necessary to ensure the learner does not get the timeline out of sync with the video. This No Autoplay Course Example incorporates those techniques.
Is there an easier way to stop slides from autoplaying?
Would Articulate consider adding an autoplay option to Storyline’s player?
If Articulate included this option as part of the player controls, it would be significantly easier to implement and be available on most Storyline courses. This would allow learners to toggle autoplay on or off, similar to how platforms such as YouTube operate. Authors would not need to dedicate time to configure this option.
My last suggestion is to consider incorporating a manual check tab in Storyline’s accessibility checker. The checker currently does not guide authors on how to review the focus order of each slide. The checker could provide guidance on how to use the focus order tool and check the color contrast of each slide. It could also provide information about accessible button names and how to ensure they are consistently represented across button states. For example, PowerPoint will flag a slide as having a read order issue if the order is different than how the content is presented visually on the slide. The author must manually check the read order to confirm that it is correct. Storyline could implement a similar feature or use AI to provide some guidance on potential focus order issues.
Thank you for your time, and I appreciate any feedback you can provide.
4 Replies
Hi AustonStamm
I think the bigger point here is that passing the Accessibility Checker does not necessarily mean the accessibility review is finished.For something like video controls, I’d test the published course with the keyboard and check whether the controls behave as expected. If a screen reader is part of your testing requirements, I’d test that as well.
I’d also check whether Storyline’s player controls and any custom video controls are both exposed to the learner. Two separate control sets can create a confusing experience even when the individual controls are accessible.
A useful workflow is:
Scan → verify → fix what you can → manually test → rescan.
I put together a practical guide for working through accessibility findings in Storyline:
Hi AustonStamm,
Thanks for taking the time to share such thoughtful and detailed feedback. I appreciate you explaining your experience and including examples of the challenges you've encountered.
I can see how enhancements such as integrating transcripts into the Storyline player, adding a global autoplay option, and expanding the Accessibility Checker with more manual review guidance could make it easier to create accessible courses while reducing the need for custom workflows.
I also wanted to mention that Storyline 360's AI Assistant can already generate captions automatically. You can review and edit them before publishing to ensure they're accurate. Your suggestion to extend that workflow further, such as automatically generating transcripts, is valuable as well.
I've shared your feedback with our product team. We're continuing to track these needs, and we appreciate you taking the time to explain how these enhancements could improve both the authoring and learner experience.
I agree with all this feedback AustonStamm
From an accessibility perspective, a single, consistent set of controls is generally preferable to two independent control systems that can fall out of sync. It would be helpful if Articulate could provide examples of recommended implementation patterns that avoid duplicate controls while still meeting accessibility requirements.
I also support the suggestion to expand transcript support. If transcripts were integrated directly into the Storyline player, authors could provide captions, transcripts, and playback controls within a single, consistent experience.
Lastly, adding a manual review section to the accessibility checker would be ideal. I also really appreciate the way PPT provides a way to review reading order across a project.
Hi NicoleLetoile-3,
Thanks for adding your perspective to the discussion.
I can see how having a single, synchronized set of media controls, along with transcripts integrated directly into the Storyline player, could create a more consistent and accessible experience for learners. I also appreciate your suggestion to expand the Accessibility Checker with guidance for manual reviews, similar to PowerPoint's approach to reviewing reading order.
I've shared your feedback with our product team. Thanks again for taking the time to add your perspective.
