NVDA 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.Accessibility Checker Results Export?
Is there a way to export the full results of the accessibility checker? Our Accessibility office is trying to work with us on changes necessary and they don't have a license to access the software. We want to be able to easily share the results with them. I am also registered for the Yukon Learning Accessibility course in Feb. 2026.Screen reader focus placed at the bottom of new content
Hello! I perform accessibility evaluations for my organization and recently noticed a screen reader barrier than I had not seen in previous Rise 360 trainings. When completing a section within a module and selecting Continue, the screen reader focus is placed at the bottom of the content, making it appear as though no new content has loaded unless the user navigates backwards or to the top of the page and through all of the previously loaded content. This doesn't happen when hitting Continue to load more content within a section, only when completing one section and moving into the next. (I apologize for not knowing platform specific terms, I haven't built a course myself!) I'm wondering if anyone else has encountered this, and whether it might be due to one of the recent updates, since this was a training newly exported in the past week. Thank you to anyone who might know more!External Accessibility Testing Tools for Non-Traditional Websites
Our team is using Storyline's built-in accessibility checker to enhance the accessibility of our courses. To further ensure our content is accessible, we're looking for recommendations on external programs that have proven effective for testing accessibility on non-traditional websites.[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.Screen reader only text
A technique that is commonly used in web development, for accessibility, is to provide text that is available only to screen readers. The text is visually hidden, but can be accessed by text-to-speech and text-to-braille readers. An example usage may be, an image has been used as the heading of the page (maybe a specific font was required). Whilst an ALT text value on the image can describe it and relay the text contents, it cannot provide the same semantics an <H1> element can. Heading elements provide essential structure to the document for assistive tech users, and also provide really handy shortcuts for navigating through a document. <style> .screen-reader-only { position: absolute; width: 1px; height: 1px; padding: 0; margin: -1px; overflow: hidden; clip: rect(0, 0, 0, 0); border: 0; } </style> <img src="https://thumbs.dreamstime.com/z/multi-ethnic-group-people-holding-text-diabetes-45539467.jpg?ct=jpeg" alt="" /> <h1 class="screen-reader-only">Diabetes</h1> Whilst we can't leverage CSS in Storyline, we can achieve the same outcome for accessibility. Using the same example illustrated above, we have a visual heading. The first step would be to ensure the image itself, is not visible to screen readers, by right clicking the image, selecting Accessibility and ensuring that the checkbox labelled Object is visible to accessibility tools is not selected (check mark is cleared). The next step is to relay this same information to screen readers. Start by inserting a text box on the slide and enter the same text that appears within the image. Then select the text you have just entered using CTRL+A. Then from the Text Styles drop-down menu, select the appropriate mark-up, in this instance, Heading 1. The next step is to check your Focus Order and make sure the new text H1 is in the correct reading order for screen readers. The final step is to emulate the "visually hidden" component of the solution. The most common methods I use is to either: Position the text behind the image that it represents, or Position off the slide (the content will still be accessible, even when position off screen). My first preference is to try and keep on the slide, and in a similar location to the image, but sometimes this is not possible, due to animation that is occurring on the slide, as I like to have screen reader text available right away. Following are the results. The video (attached) demonstrates the difference between ALT text and hidden text and the benefits of semantic mark-up.
