Closed Captions Only Displaying on First Line of Video
I'm experiencing an issue with the closed captions on my Storyline 360 imported videos. The captions only appear on the first line of the video and then disappear for the rest of the playback. This is happening even when I manually type the captions or try importing .srt or .vtt caption files. I recently updated Storyline 360 on August 27th, and this issue started occurring after that update. Has anyone else experienced this problem? I've tried troubleshooting it but can't seem to find a solution. Any advice or insights would be greatly appreciated. I'm hoping this is just a temporary bug that will get resolved in a future update, but in the meantime, I'm struggling to get my videos properly captioned. Thank you in advance for your help!Table with row headings
I need to be able to create a table in either Storyline or Rise that has both column headings AND row headings, and I need it to be 508 accessible and properly read out both headings along with cell contents. As best I can tell, both products only support column headings. The recommendation is to use an image of a table and then describe it in alt text, which I know my 508 auditor will not accept. Has anyone found a solution to this?Bug dans l'ordre du focus et NVDA
Bonjour, Je vous écris car je remarque un gros bug dans l'ordre du focus sur Storyline. Je suis en train de créer une liste déroulante avec les éléments de liste qui s'affichent dans un calque. A chaque fois que je clique sur un élément de liste, cela à normalement pour effet d'attribuer une valeur à une variable et de fermer le calque. Le comportement attendu (et qui fonctionnait avant) est que lorsque le calque est fermé le focus se remet sur le bouton qui a ouvert le calque en question. Or, lorsque je clique sur le dernier élément de liste, le focus semble visuellement fonctionner correctement (NVDA affiche un contour en couleur sur le bouton qui affiche la liste) mais NVDA lit l'aria-label de l'élément suivant (dans mon cas bouton "valider") pour ensuire lire correctement l'aria-label de mon bouton de liste. J'ai fait plein de tests est le bug persiste. Il n'y a aucune logique dans ce bug 😅 J'ai remarqué d'autres bugs du même type. Tout fonctionne à la navigation au clavier mais avec un lecteur d'écran c'est la cata. Voici un lien vers le Review : https://360.articulate.com/review/content/46333b49-dcb2-4e74-8435-198af003c106/reviewProcess Block Accessibility Issue
I perform accessibility testing on a lot of Rise content, and one of the most frequent issues I raise is the focus order of the "Next" button for the first slide of the Process Block potentially causes problems for screen reader users. The issue is, that when using a screen reader, the "Next" button appears in the focus order prior to the content on the first slide. This means that a screen reader user could miss the content on the first slide if they were to go ahead and select the "Next" button (which seems logical) rather than continuing down the page to the contents of the first slide. My suggestion would be to remove, or add an aria-hidden="true" to the Next button for the first slide. This would then allow screen reader users to continue down the page to the contents of the first slide and use the START > button instead. I'm sure I have logged this as an issue in the past, and will do again, but just wanted to raised it here so I can track the issue.Question accessibility
Hello, I have a question regarding the accessibility of modules, specifically about handling questions. I'm working on the focus order, and I noticed that the focus order of a slide also includes the elements of the feedback layers (see screenshot, sorry it is in french^^ but you'll get it). Does this mean that a learner using a keyboard or screen reader will encounter the positive and negative feedbacks before even answering the question? How do you handle such cases? What are your recommendations? Thank you!
