AI Audio + Pronunciation + Correct Closed Captions
I'm having an issue with the new AI Audio feature in Storyline, as it relates to pronunciation and generating CCs. In the past, using Text-to-Speech, I often needed the voice to pronounce something differently than how the word appeared. I'd generate and insert the voiceover with "Generate Closed Captions" checked: "Welcome to Brivo." Then I'd go back into that voiceover, change the words to phonetic spelling according to how I needed them pronounced, uncheck "Generate Closed Captions," and insert: "Welcome to Breevo." This would result in correct CCs and correct pronunciation. The audio would state "Welcome to Breevo" while the CCs would read "Welcome to Brivo." I'm unable to duplicate this workflow using AI Audio. When I uncheck "generate CCs," it simply does not insert any CCs at all. I'm left having to waste so much time generating and re-generating audio in hopes that it randomly pronounces all my words correctly. Has anyone figured out a workaround for this issue? Am I just not using the tool correctly?Storyline Zoom to fit & Accessible text
Hi everyone!👋 Our team has enabled Zoom text fitting and accessible text features in our Storyline learning courses. Should we include these features and their usage in our navigation or control guide? I’d also love to hear your best practices to ensure we are providing the most accessible courses to our learners. Thanks in advance! 🤩New Storyline Accessibility bug
Hello There seems to be a brand new bug since the October 22 update. When a button that was previously disabled is changed to normal, the screen reader and keyboard still pick it up as disabled - it reads as 'button unavailable' and is ignored by the tab and cannot be selected by the keyboard. However, the state shows as normal with the hover state working properly and it can be clicked with a mouse. This seems to happen in specific circumstances - The trigger to change the button from disabled to normal is "When the timeline starts on this slide" and the button has an entrance animation. Normally I would just ditch the entrance animations but it worked fine before the October 22 update when we accessibility tested it, the course including animations has been signed off by our client and entrance animations are blinging anyway. Here is an example module. The current version was published using todays November update and the slightly older version was published using the October 8 update to Storyline. I would also rather not roll back Storyline to republish as there are a whole bunch of recent bug fixes that I need. https://360.articulate.com/review/content/c5e0d117-32d3-4a2b-b91b-f5e4504765a3/reviewDialogue accessibility
Hi! Just wondering if this is expected behaviour. When a dialogue is displayed and then closed again, the screen reader: Reads the label of the dialog after the dialog is closed (or it says 'dialogue' if there is no label) Once it gets to the end of the focus order, reads the most recently visited dialogue label (or 'dialogue' if no label) again. It seems to focus on the whole slide when it does this. It happens before it gets to the player controls. Bonus weird thing/bug: If you activate NVDA then click with your mouse on elements (including ones that are hidden from accessibility), when you go back to keyboard control, the elements you clicked on also get added to the end of the focus order before the player controls. https://360.articulate.com/review/content/985a380f-0762-4823-b2f1-62f0f3ba2bac/reviewHow to play audio files by hovering over text
Hi all, For all you Javascript gurus out there... I am trying to create a storyline file that caters for accessibility and in this case plays a unique audio file every time you either hover over or click a piece of text on the screen and then stops when you hover or click on another line of text. For example, if you had 2 headings on the screen saying "Section One" and "Section Two", the respective audio will play for these. Now, I went on Microsoft co-pilot and asked it the following:- "Write a javacript function in Articulate Storyline where if you click on a some text, it plays an audio file, let's say that this is called sound1.mp3 but if you click on another piece of text, sound2.mp3 plays and sound1.mp3 stops." It actually wrote some javascript and gave me instructions how to implement it within Storyline. So... I went ahead and done this, tested it and found out that for some reason it is not working! I have looked at the javascript and for the life of me, I cannot see why this cannot work! I have attached the source file if anyone would like to take a quick look! Thanks in advanceJaws Multiple choice question not pausing for periods when sentences are ending with a number.
Jaws Multiple choice question not reading/pausing for periods when sentences are ending with a number. If my first sentence end with "1." Next sentence, Jaws will not pause for the period. If my first sentence end with "1a." (or any letter), Next sentence, Jaws will pause for the period and read the next sentence. Temporary solution: Added a space before the period to fix this.NVDA issues in Storyline 360
We are on our accessibility journey and looking for some input around screen reader experiences. We understand that learners using screen readers need to arrow down to move through onscreen text and that they can tab or arrow down to move through interactive elements. We also understand that learners can select interactive elements by selecting the Spacebar or Enter key. While testing a published file with a screen reader, we ran into some unexpected behaviors as described for the slides in the attached file. Software used: Storyline 360 x64 v3.93.33359.0 Parallels for Mac 20.1.1 running Windows 11 Microsoft Edge v130.0.2849.80 (official build) (arm64) NVDA 2024.4.1 Learning Check, Question 1 is a multiple choice question with customized feedback layers. We understand that the answer options are treated like a button set. This interaction follows the screen reader navigation as posted at https://access.articulate.com/support/article/Storyline-Navigate-Multiple-Choice-Questions-with-a-Screen-Reader-or-Keyboard. It was unexpected but wonderful that the reader reads the feedback without any further prompts after the screen-reader-user learner selects Submit. Learning Check, Question 2 is a multiple response question with customized feedback layers. We understand that unlike the multiple choice interaction, each answer option is treated as an independent interactive object. Also unlike the multiple choice interaction, it is cumbersome and somewhat confusing for screen-reader-user learners to get to feedback. Are we missing something to make it an easier process for these learners to get feedback? Step by step through the behavior Expected: After using arrow down as the reader reads the heading and question text, the learner can arrow down or tab through answer options, selecting Spacebar to check or uncheck answer options. Tabbing past the last answer option, the reader announces “Back to top button”. If the learner is ready to submit answer choices, they can… Not Expected: …tab past the Back-to-top button, reader announces “Miscellaneous controls region…” and they must tab through all bottom Player frame settings from left to right to get to the Submit button to select Spacebar, reader announces “unavailable”. At this point, the learner cannot easily get back to the slide to receive feedback. The learner must use Shift+Tab or up arrow to cycle backwards through the bottom player frame controls until they hear “Out of region, Back-to-top button”. Learner must select Spacebar. When they do, reader announces “Blank”. Learner must then arrow down so the reader will read feedback. Expected: …use the keyboard shortcut to select Submit, … Not Expected: …silence / no reader announcements or cues even though I can see the feedback layer reveal but with Back to top button highlighted. If learner tabs or down arrows again, reader announces “Miscellaneous controls region…” The learner must select Shift+Tab or Up arrow, reader announces “Back to top button”, learner selects Spacebar, reader announces “Blank, Clickable main landmark heading level 2 [H2 text]”, arrow down, reader reads feedback text. Expected: …select Spacebar to go back to top and then use the keyboard shortcut to select Submit… Not Expected: …silence / no reader announcements or cues even though I can see the feedback layer reveal. Learner must arrow down, reader announces “Blank, Clickable main landmark heading level 2 [H2 text]”, arrow down, reader reads feedback text. “Crane safety” is an interaction with buttons on the base slide to reveal information located on a layer. After a screen-reader-user learner listens to VO and arrows down to listen to the reader read through all onscreen text on the base layer, they can move through the interactive buttons either by using the Tab or Down arrow key. However, using the down arrow to move through the interactive buttons results in unexpected and confusing behavior. According to the information in the article titled Storyline 360: Slide Content is More Accessible, subsection Navigation Is Easier this should not be the case. What do you recommend to resolve this issue? Step by step through the behavior Expected: If the learner tabs to the first button, the reader reads “[Alt text] button”, learner selects Spacebar or Enter, reader announces “[button name] button”, learner tabs through remaining buttons until the reader announces “Back to top”, learner selects Enter, reader announce “Blank”, learner arrows down to listen to the reveal layer text, reader reads heading on the base layer when learner arrows down past end of text on the reveal layer. Unexpected: If the learner arrows down to the first button, the reader reads “button [Alt text]”, learner selects Spacebar or Enter, reader reads a small portion of text on the reveal layer starting in the middle of the text before announcing “[button name] button”, learner arrows down through remaining buttons until the reader announces “Back to top”, learner selects Enter, reader announce “Blank”, learner arrows down to listen to the reveal layer text, reader reads heading on the base layer when learner arrows down past end of text on the reveal layer. “Vehicles” is an interaction with buttons and information on both base and slide layers. Screen-reader-user learners are able to arrow down to listen to the reader read through all onscreen text on the base layer. Because the navigation text is not read immediately before the interactive arrow buttons, the learner will likely use the down arrow key to select them. We have also tested this slide to make sure to tab to the interactive arrow buttons and experience the same reader behavior as described below. Can you please provide an explanation for this behavior? Step by step through the behavior Unexpected: When the learner selects Spacebar or Enter on the first arrow button below the required checks text, the reader announces “list with four items” but reads only the last bullet. The H1 heading and first three bullets on the base slide are not read. Expected: The learner continues to arrow down past text on the base layer until reader announces “Button back to top”, learner selects Spacebar or Enter, reader announces “Blank”, learner arrows down as reader reads text on the layer, learner arrows down to the arrow button. Unexpected: When learner selects Spacebar or Enter on the arrow button below the seatbelt text, reader reads the last few words of the text on the layer then immediately reads text on the base slide without breaks from H1 heading through the end of the navigation text. When the learner arrows down, the reader announces “list with four bullets” and starts reading the first bullet on the base slide again. The learner must arrow down to have the reader read the remaining text on the base slide. Expected: The learner continues to arrow down past text on the base layer until reader announces “Button back to top”, learner selects Spacebar or Enter, reader announces “Blank”, learner arrows down as reader reads text on the layer, learner arrows down to the arrow button the parking break text. Unexpected: When learner selects Spacebar or Enter on the arrow button below the seatbelt text, reader reads the first bullet on the base layer then immediately reads text on the base slide without breaks from H1 heading through the end of the navigation text. When the learner arrows down, the reader announces “list with four bullets” and starts reading the first bullet on the base slide again. The learner must arrow down to have the reader read the remaining text on the base slide. Expected: The learner continues to arrow down past text on the base layer until reader announces “Button back to top”, learner selects Spacebar or Enter, reader announces “Blank”, learner arrows down as reader reads text on the layer, learner arrows down to the arrow button the reversing vehicle text. This cycle continues with the reader reading a few words of text either on the layer or the base slide before reading the entire Any help is greatly appreciated. Thanks in advance!Recent Accessibility Upgrades in Storyline
Happy release day, everyone! Storyline update 94 includes the following accessibility improvements for a better experience: Fixed: Keyboard navigation worked inconsistently when interacting with 360° images. Fixed: Screen readers didn't always announce layer content. Click the Update button for your Storyline app to check out all the latest goodness.
