Rise 360 Q1 2026 Accessibility Updates
We recently posted a new update in the Rise 360 Accessibility Journey, highlighting some of the accessibility improvements and enhancements delivered during Q1. From the new and improved sorting activity to expanded audio support, this work reflects our ongoing commitment to building more inclusive learning experiences for all learners. The update also includes links to our revamped conformance reports and maturity plans for both Storyline and Rise. Accessibility is never a one-time effort, and we’re grateful for the feedback, insights, and conversations from this community that help shape our work. Do you have a Rise accessibility improvement or resource you'd like to see next? Let me know in the comments! Read the full update here: Rise 360: Our Accessibility JourneyPlayer 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.iFrame video becoming a keyboard trap
We have several Rise tutorials that use YouTube content embedded using iFrames. Doing accessibility testing, we recently discovered that these become keyboard traps. Users can tab into the content and play it, but the standard guidance of using esc to navigate out of the video isn't working and tabbing through also doesn't seem to work. Does anyone have insight into what we need to do to make this content fully keyboard accessible? Has anyone else had this issue? Thanks!In Case You Missed It (ICYMI): Accessibility Updates in Q1 2026
Welcome to our Q1 2026 update! This quarter, we focused on improving how training integrates with assistive technologies while reducing the effort required to build accessible content. With expanded AI support for alt text and captions, better screen reader announcements, and more fully accessible interactions, it’s now easier to create training that works for a wider range of people. Our community continues to grow. We now have 916 members, an increase of 92 this quarter. We’re glad you’re here. Let’s take a look at what’s new this quarter! Product Updates Rise New: Do even more with knowledge check blocks, quizzes, and question bank questions by adding audio. Enhanced: Quiz timer announcements are available for screen readers, as well as a timed quiz section in screen reader announcement labels. Enhanced: Sorting Activity blocks are now fully accessible. Enhanced (Beta): Localize custom blocks with Articulate Localization to maintain consistency across every language. Fixed: Screen readers couldn’t read modified text labels for media player buttons. Storyline Enhanced: Manage AI-generated alt text suggestions as you work directly from the Size and Position window or the media library. Enhanced: AI alt text suggestions generated by the accessibility checker are saved throughout your workflow, keeping bulk-generated suggestions available until you review them. Enhanced: The accessibility checker now displays a distinctive icon when AI-generated alt text suggestions are awaiting review. Enhanced: Speed up your accessibility workflow by generating captions directly from AI Chat. Enhanced: Deliver accessible surveys with a built-in Likert scale question that supports screen readers and keyboard navigation. Enhanced: Get AI-generated alt text suggestions automatically when you import assets, making your courses more accessible with less effort. Enhanced: Link and file icons in the resources player tab now meet accessibility color contrast guidelines. Fixed: Slide content shifted when navigating to objects at the bottom of a slide with a JAWS screen reader. Fixed: NVDA screen reader users could access hidden scrollbars in player tab content. Fixed: The closed captions editor showed captions for text-to-speech narration even though caption generation was turned off. Fixed: The accessibility checker skipped markers when checking interactive objects for the minimum target size. Fixed: Keyboard navigation didn’t work for hyperlinked text inside shapes or text boxes with triggers. Fixed: Screen readers didn’t read alt text for object states if the original object was deleted or the normal state didn’t have alt text. Fixed: In pick-one and pick-many interactions, screen readers announced SVG checkboxes as checked before learners selected their answer. Fixed: JAWS screen readers announced numbered lists incorrectly. Fixed: The accessibility focus indicator was misaligned when text was animated by paragraph. Fixed: The Keyboard Shortcuts window didn’t display all available commands because the scrollbar didn’t work. Fixed: Screen readers announced check boxes and their alt text as separate elements. Fixed: Center-aligned text shifted left when the Accessible Text setting was enabled on the player. Fixed: Hyperlinks sometimes behaved erratically during keyboard navigation. Other Updates Interested in building your accessibility skills with others? Join our upcoming Accessibility Peer Pod in Q4. New Articles Storyline 360: Improving Video Accessibility with Audio Descriptions Updated Articles Update to Storyline 360: Our Accessibility Journey HUGE update to the Rise 360 Accessibility Journal! Accessibility Index Updated Rise and Storyline maturity plans: Improved the resolved section with clearer, more positive language and reordered updates so the most recent information appears first. Updated VPATs to better reflect the role of authors and include AI Assistant where applicableAccessible 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 advanceNVDA Keyboard Navigation Issue in Process Block (Step Progression)
I’m testing the Process block for keyboard and screen reader accessibility using NVDA and wanted to confirm expected behavior. Initially, NVDA reads the step buttons (Step 1, Step 2, etc.) along with the left/right navigation arrows, and then proceeds to read the content of Step 1. After the Step 1 content is read, pressing Tab moves focus to the next interactive element in the following block, rather than moving to Step 2. At the moment, the only way to reach Step 2 is by using Shift + Tab to go back to the step buttons and activating it. Is this the expected keyboard interaction for the Process block, or should Step 2 be part of the natural tab order immediately after the Step 1 content?New 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!
