storyline 360
21 Topics[REDUNDANT] Storyline custom focus control
========================================================================= Update 18 March 2025 This functionality is now redundant. Please use the native focus trigger in Storyline 360 64 bit March 18, 2025 (Build 3.98.34222.0) ========================================================================= There have many been times, when using Storyline to develop content, it has not been possible to get the kind of screen reader focus control that I have needed. Using layers for this can only get you so far. I developed a JavaScript function that allows you to send the screen reader focus to the text field that you want, via any trigger. Adding the following JavaScript to your projects Slide Master will make it available throughout your module: // Check if function has been defined already if (typeof window.setFocus === "undefined") { // Get reference to the Storyline Player var $player = GetPlayer(); // Set the amount of time to delay before attempting to send focus to the target element (milliseconds) 1000 = 1 second. var $interval = 200; // window.setFocus = function ($target, $announce = false) { // Get the target element, based on the passed argument setTimeout(function () { var $div = document.querySelector('[data-acc-text^="' + $target + '"]'); var $id = "acc-" + $div.dataset.modelId $div = document.getElementById($id); if($announce) { $div.setAttribute("aria-atomic", "true"); $div.setAttribute("aria-live", "assertive"); } // Send focus to target, after defined $interval $div.focus(); }, $interval); } } Once the function is defined in your Slide Master, you can then call the function on the page using a JavaScript function, which can be triggered by any Storyline trigger such as timeline start, timeline end, button click etc. // The second argument will determine if the content should // be announced to assistive technology using aria-live=assertive // This will announce the text contents to the screen reader window.setFocus("Customer in the queue", true); // This will just send focus to the element. window.setFocus("Customer in the queue", false); The first argument, which is passed in the "" quotes, is the text contents of the text field you are targeting. You do not have to include all the text, just enough to ensure it is unique. For example, if you have two text fields: "Customer in the queue talking on their phone." "Customer in the shop staring into space." Passing the words "Customer in the" would not be specific enough, as there would be two text fields found. However, passing "Customer in the queue" would send the focus to the text field that contains the text "Customer in the queue talking on their phone." The second argument (true or false) determines if the target elements contents should be announced to the screen reader when it receives focus.866Views1like11CommentsIn Case You Missed It (ICYMI): Accessibility Updates in Q2 2026
Welcome to our Q2 2026 update! This quarter continued our focus on supporting the creation of accessible training and improving the learner experience. From new capabilities for identifying accessibility improvements to refinements for screen reader users, keyboard navigation, and color contrast, these updates reflect our ongoing commitment to accessibility across Rise and Storyline. Our community continues to grow. We now have 970 members, an increase of 54 this quarter. We’re glad you’re here. Let’s take a look at what’s new this quarter! Highlights This Quarter This quarter's accessibility updates centered around three themes: Identifying accessibility improvements earlier Storyline Labs introduces an experimental Color Contrast Check that helps identify color contrast issues across an entire project, while updates to Rise theme colors ensure contrast is calculated correctly across supported theme elements. Giving authors more control Storyline now lets you choose which objects are visible to screen readers, giving you greater control over how your training is presented to assistive technologies. Improving the learner experience Across Rise and Storyline, we refined screen reader support, keyboard navigation, focus management, and question interactions to provide a more predictable experience for learners using assistive technologies. Together, these updates continue our focus on supporting accessible training and improving the experience for everyone who creates and completes it. Product Updates Rise Enhanced: To improve accessibility, we've globally applied WCAG 2.1-compatible contrast to theme color elements that previously had contrast calculated incorrectly. Enhanced: Improved screen reader focus behavior so that, after answering a knowledge check, focus moves directly to the next relevant content. Enhanced: Improved tooltip behavior so that only meaningful tooltips are displayed for interactive elements like the block selector and sorting activity. Enhanced: Preview now opens the entire course, with full navigation. Enhanced: The video player is now consistent across the app and provides a refined experience with better responsiveness on mobile devices. Storyline New: Easily control which objects should be visible to screen readers with a new accessibility toggle in the timeline. New: Storyline Labs is here! Access experimental features early from the Labs button in the File or View tab. Available in Labs: Color Contrast Check helps identify color contrast issues across an entire project using the accessibility checker. Fixed: Screen readers announced extra text when certain question types were used. Fixed: A trigger designed to fire with a user click incorrectly executed when using a screen reader. Fixed: Text-entry fields didn't follow the defined custom focus order during preview. Fixed: Windows Narrator read bulleted and numbered list items twice. Fixed: Screen readers didn't correctly announce nested list items in the Notes panel. Fixed: The accessibility checker incorrectly reported issues on screen recording slides where all objects were hidden from accessibility tools. Fixed: The focus order was incorrect for screen readers when the Transcripts tab was opened. Fixed: Drop-down question choices didn't display a scrollbar when the list couldn't fit all choices. Other Updates Updated Articles Storyline 360: Working with Buttons Rise 360: How to Use Process Blocks Rise 360: Our Accessibility Journey Storyline 360: Our Accessibility Journey Storyline 360: Working with Variables Storyline 360: Working with Triggers Storyline 360: Pick-One Questions Accessibility Index27Views0likes0CommentsNew in Labs: Color Contrast Check in Storyline 360
Hello, my fellow a11y friends! We just launched the new Color Contrast Check inside Storyline Labs, and it’s ready for you to try out! This feature integrates directly into your built-in Accessibility Checker, making it easier than ever to catch text and object fill contrast issues before you publish. No extra tools required. We want to build the best possible version of this tool, which means we want to hear from you. Turn it on in your Labs settings today, test it out on your current projects, and let us know what you think. Check out the New in Labs: Color Contrast Check in the Accessibility Checker post for more details!138Views0likes4CommentsAccessibility Checker - Switch off accessible objects
I'm using the accessibility checker to make all my courses 100% accessible. I open the project file, run the checker and go through each line, one by one. The most common error is an object (rectangle / line / icon) not being accessible. Why does a horizontal line ever need to be accessible? So I'm going through turning them all off as they don't need alt text. This is painful, some project files have 000s of errors. Is there a quick way to untick the accessibility of all shape type objects. Icons from the media library are grouped and the main group and its elements all need to be switched off. The acc checker doesn't allow multi select and when in the timeline selecting all and unticking doesn't always work. Its taking forever!360Views4likes8CommentsAccessibility - Screen Readers and TTS
Hi, I'm currently completing an apprenticeship in Digital Learning Design, and I'm working through some content on accessibility. Previously, all our storyline courses had text-to-speech added on, but the accessibility features such as alt text and focus orders weren't used. Since I've learnt more about screen readers through my apprenticeship, I've been following correct processes and designs for best practice with screen readers. However, as these read out the text on screen, I'm wondering if the text-to-speech I manually add onto all slides is still required? Part of me thinks it might be too much if both the audio on the course and the screen reader are reading the content out loud, but then we might have learners with dyslexia, for example, who might not require a screen reader but still prefer to have the text read aloud. How does everyone else navigate this? Do you use both or one or the other? Thank you!80Views0likes3CommentsNVDA Storyline 360 Software Simulation Issue
Hello all, I have been working on a software training course for a while, but I cannot share the product file, so I have tried my best to replicate the issue with a brief PowerPoint activity. My current project file has 6 scenes and 452 slides. I am looking for the easiest fix to the issue at this point, while avoiding backtracking on work. Any assistance would be GREATLY appreciated as I am close to my wits' end. Below is a synopsis of the issue, the fixes I have tried, and the attached PowerPoint Activity project file. Build Background: I used the screen recording features in Storyline 360 to create both Try Mode Steps and Test Mode Steps for scenes in the course. I turned off Show Animation in the Capture Action Fine Turning. I have ensured that hotspot and text entry interactions are at the top of the timeline, above all other elements. I have deleted triggers where possible, but some of the Play Video Screen Recording Action When the User Clicks Hotspot 1 remain, as the program won't allow them to be deleted even after turning off the animations, so I have disabled them. I had to make additional cover-ups to hide employee IDs and information, as I did not have a fake user account. The cover-ups have been hidden from accessibility tools. Issue: When navigating the course with NVDA and Microsoft Narrator, the Try Again layer keeps deploying as the user selects the hotspot button for a second and announces "Incorrect," which will lead to annoyance and confusion for the learner. The Try Again layer does not deploy in the Test Mode Steps scenes, but it does in the Try Mode Steps scenes. The Try Again layer does not deploy when using keyboard navigation without a screen reader enabled. I do not want to remove the Try Again feedback, as it is important for sighted users. Triggers on Base Layer: When the user clicks outside Hotspot 1 - Show layer Try Again When the user clicks Hotspot 1 - Jump to slide next slide (Disabled) When the user clicks Hotspot 1 - Play video Screen Recording Action Triggers on Try Again Layer: When user clicks Try Again - Hide layer this layer Solutions Tried But No Success: Running the file as a published SCORM in test environment, Review 360, and in preview mode- Try Again layer still deploys in all environments. Expanding the hotspot area beyond the identified bounds. Changing the order of the user clicks outside Hotspot 1 and the user clicks Hotspot 1 triggers on the base layer but Storyline 360 does not allow me to change the position of these triggers under Hotspot 1 in the trigger menu. Adding back in the correct layers of the screen recording as shown in scene two of my attached example.Solved562Views0likes6CommentsPlayer Setup Recommendations for 508/WCAG 2.1 AA: Menu, Transcript, Navigation Buttons
Lately, I’ve been seeing an increased focus among organizations and government entities on ensuring Storyline courses meet WCAG 2.1 Level AA and Section 508 standards. While Storyline 360 offers several ways to create accessible content, I’m looking for general best practices for configuring the Storyline player so that it is straightforward for developers to implement while also providing a seamless experience for screen reader and keyboard users and meeting these requirements. I would love to hear your recommendations on the most effective way to set up the player, whether that means using the built-in player features or developing a custom navigation interface. Specifically: Transcripts & Glossaries: Do you recommend using the built-in player tabs, such as the Notes panel and Glossary tab, or is it better to build custom on-screen versions? If using the built-in player, does the Notes panel function sufficiently to meet accessibility requirements, or would you recommend a different approach for transcripts? If you do use the Notes panel, do you recommend placing it within the menu sidebar or at the top? The Menu: For menus that outline the course structure, do you recommend excluding it to reduce “tab fatigue” for screen reader users, or including it so learners can better track their progress? If a menu is included, do you prefer using the built-in Storyline menu or creating a custom one? If you use the built-in menu, is it best practice for the sidebar to start collapsed to keep the focus on the main content, or expanded for easier access? Also, when using the built-in player menu, do you recommend including subheadings? Navigation Buttons (Next/Prev): Do you recommend using the built-in Next/Previous buttons or adding custom on-screen buttons? While I know the built-in buttons now support accessibility shortcuts, many developers still seem to create their own Next/Previous buttons. I assume this is to provide a more intuitive end-of-slide experience. In any case, I would value your suggestions and would especially appreciate understanding the reasoning behind the recommended setup.265Views0likes2CommentsStoryline: Freeform radio group labels affected by timeline order and focus order
I think the behavior I describe below is a bug, but please let me know if this is intentional. Background Information Storyline now automatically publishes a group label for radio button sets. JAWS will read "group start ___" and "group end ___" around each radio button set. NVDA reads it once at the beginning of the radio button set, I believe. I think this behavior was updated in v3.111 (Feb 21 2026) since I can take a slide between v3.110 and v3.111 without doing anything to it and it won't add the group labels on publish to my slide in v3.110. I believe the reason this feature was added was to address WCAG 1.3.1 guidelines surrounding group labels for form field sets. (Rise already has group labels automatically added.) However, I don't see any mention of it in the Storyline 360 version history. Situation - potential bug For freeform questions, the "___" portion of the announcement (the group label name) depends on two things: Which textboxes are below the answer options in the timeline (this includes textboxes on the master slides - they are treated as "below" the answer options) Of those textboxes, which one comes first in the focus order (a textbox has to be in the focus order to be used for the group label) Storyline will use whichever textbox is below the answer options and first in the focus order as the group label. The layer position of the textbox in the timeline shouldn't have any effect on the group label, correct? Is there someplace we can actually set the group label without having to use the above mentioned rules as workarounds to get it to say specific things for the group label? Here's a Review 360 slide, and storyline file attached. group-labels | Review 360Solved445Views1like3CommentsAccessible systems training
Hi all, I was wondering what people's thoughts are on best practice of making systems training in Articulate Storyline360 accessible, targeting WCAG 2.2 AA. Presumably the system being recorded itself needs to be accessible to this standard for users. How does the built in screen recording show me/try me type content behave with screen readers and key board navigation? Any experiences from end users that use assistive technologies, that have been through systems training? Thanks in advance401Views0likes1CommentNew Audio Descriptions Resource
We recently published a new article on improving video accessibility with audio descriptions in Storyline 360. If your videos include important visual details, such as on-screen text or charts, audio descriptions help ensure that learners who are blind or have low vision can access key information. In this resource, you’ll learn: When to use audio descriptions Differences between standard and extended descriptions How to add them in Storyline 360 Tips for writing effective descriptions How WCAG guidelines apply Are you using audio descriptions in your courses? Are there other accessibility topics we should cover? We want to hear from you!162Views2likes0Comments