Issue with languages on images - text translation
I have a Rise course that is in English and I used the new Articulate Localization/translation service to have it translated into Italian, and that part is fine. What is NOT fine, however, is that, throught the course are images that have text on them (see attached), that I assumed would translate with the rest of the course. I understand that the text on the images does not translate, so I had the text on those images translated separately - WITHIN Rise, in some instances...and each time I replaced the pictures in the Italian version with pictures that had Italian text, the images in the original English were also replaced with the now-Italian text versions. So, either my pictures are forced to be in Italian, even on the English version, or they are forced to be in English, even on the Italian version. How can we fix this? I have to have this translated into German, French and Spanish, too, so how do I ensure that those versions have the appropriately imaged pictures? Do I have to make a separate module for each different language? Screenshots included are one of the images - the original English, then in Italian. Also a screenshot that shows the English module with the images in Italian, when they should be in English.JAWS is announcing the disabled state of the button twice
JAWS now announces the disabled state of a button twice—first when focusing on the overall button control, and again when focusing/reading the button text. In previous versions, it only announced the accessible text once followed by unavailable.Changing font size for card sorting in RISE
Hello! Is there a way to change the font size for the cards in the card sorting activity in RISE? The font is small and difficult to read. In the example below, I could remove the background image of course, I'd still like to increase the font size. I can see there is a way to change the font for flip cards but not card sorting. Thanks in advance :)Code blocks load slower than the rest of the page
The SVG code blocks we use for section transitions are slow to load. This leaves visible white gaps in the lesson and causes the page to jump as the blocks appear, making the learner experience feel broken and unpolished. We use code blocks to create SVG section transitions in Rise. These are full-width, solid-colour shapes, sometimes with waves or cut-outs etc, that visually separate one part of a lesson from the next. SVG is ideal for these transitions because it: keeps curves, waves, and cut-outs sharp at any screen size scales to the full width without cropping or leaving white slivers at the edges uses our exact brand hex colours, without compression affecting them is significantly smaller than an equivalent PNG The issue is not the SVG itself. From the browser inspect I can see that each code block is loaded inside a sandboxed iframe from sandbox.articulateusercontent.com, with loading="lazy" enabled. Lazy loading makes sense for larger or more complex embeds, but it creates a noticeable delay for small decorative blocks placed throughout a lesson. Even though each SVG is only a few hundred bytes and has no external assets, the browser still needs to connect to Articulate’s sandbox domain before the content can render. The initial connection can involve steps such as a DNS lookup and TLS negotiation, so the delay is caused by retrieving the iframe rather than by the size or complexity of the SVG. When a learner scrolls at a normal pace, two things can happen: The learner reaches the block before it has loaded. The lazy-loading buffer does not provide enough time if the learner is scrolling quickly. Instead of seeing the full-width, solid-colour transition shape, they see a white gap. The page shifts when the block appears. The block’s height is calculated after it renders and is then passed back through --block-html-height. This causes the content below it to move once the transition shape loads. A delayed text or video block is relatively easy to overlook. A delayed transition shape looks like a hole in the page, so it reads as broken rather than slow. The issue is more noticeable on patchy or variable Wi-Fi, which is common across many of our sites. The irony is that the SVG is much lighter than the image format we are avoiding. The delay comes from loading the iframe from Articulate’s servers, not from the size or complexity of our code. __________________________________________________________________________________ Anyway what we’d like to see instead: Preconnect to the sandbox domain Adding the following to the published page’s <head> would establish the connection when the page first loads: <link rel="preconnect" href="https://sandbox.articulateusercontent.com"> This would allow subsequent code blocks to skip most of the connection setup. It is a small change that would benefit any customer using code blocks, particularly in modules containing several of them. Reserve the block height before it renders The block height is already measured after loading and applied through the --block-html-height CSS variable. If that height is available at publish time, applying it before the block loads would reserve the required space and prevent the page from shifting, even when the iframe is slow to render. Also worth considering: Give lazy loading more runway The current buffer starts the fetch when the block is close to the viewport. Increasing that distance would give small blocks enough time to load before the learner reaches them, without loading everything at once. Even a modest increase would cover most normal scrolling speeds. Eager-load the first code block on a page A code block at the top of a page has no runway at all — it is already in the viewport when the page loads, so the fetch only begins after the main layout has settled. We have worked around this by never placing a code block first on a page, and that is a fair enough trade-off for us. But it is a workaround rather than a fix, and it limits how we can structure a lesson. Eager-loading only the first code block would be a targeted change with no cost to modules containing many blocks. We are not asking for lazy loading to be removed. We understand why it is useful, particularly in lessons containing multiple media-heavy embeds. We are asking whether its visible effects can be reduced for small, lightweight code blocks. Impact We are building a Rise template that will be used across our organisation, so these solid-colour transition shapes will appear in every module our team produces. The loading gap undermines an otherwise polished learner experience, and it is not something we can resolve through design or by optimising the SVG further. Preconnecting to the sandbox domain and reserving the block height would address both the delayed rendering and the layout shift without removing the benefits of lazy loading.Anyone having this 508 issue with the scrolling panel in Storyline?
I have a scrolling panel that when used with JAWS v2025.2505.43 announces the element as “left right slider” though the slider is used to move content up and down. Additionally, JAWS announces incorrect instructions for how to use the element. Is this a known issue?Build an Accessible Drag and Drop Interaction in Storyline
If you've ever needed to build an accessible course in Storyline, you may know that the built in drag and drop interactions are not accessible (see the VPAT). However, with some extra work it is possible to create your own drag and drop interaction in Storyline that is fully accessible. The issue with drag and drop interactions and accessibility is that people who access the computer using only a keyboard or assistive input device, and no mouse, cannot click-and-drag. So, the interaction must have another option, that works through the use of keyboard inputs (typically, the tab and enter keys). In Storyline triggers, anything that is done "on click" can be mimicked by a keyboard or other input device. To build a keyboard-accessible drag and drop requires building a second set of triggers that function using click-based rather than drag-based interactions. Here is how to build your own keyboard accessible drag and drop interaction in Storyline. Please note that you may include other elements that are not fully accessible. Take a look at the WCAG Guidelines to evaluate other aspects of your course creation This interaction relies on a user-selected submit button. This button needs to be on the slide, as the triggers used are not compatible with the built-in submit button in the Storyline player. Note: It will be easiest to create all layers, elements, and states before creating the triggers. LAYERS NEEDED Base Layer – Most of the triggers will be on the base layer. Correct – A feedback layer for when the user submits the interaction, when all items have been moved to the correct drop location. Incorrect – A feedback layer for when the user submits the interaction, when the interaction is incomplete or some items have been moved to the wrong location on the screen. BASE LAYER Elements Needed Drag items – one or more Drop targets – one or more Submit button – one Drag Item States Normal - The built in state. This does not need to be modified. Selected - Create a “Selected” state. Make sure to edit the selected state to include a visual indicator that the item is selected. An easy way to do this is to add a “glow” shape effect in a color contrasting the object. Drop Correct - Create the “Drop Correct” state. You may want to visually signal that the drop was completed. One way to do this is to darken or desaturate the object in the “drop correct” state. Drop Incorrect - Create the “Drop Incorrect” state. Make this state visually identical to the Drop Correct state. Triggers Submit Button 1. Show layer Correct when user clicks If Drag item 1 state equals Drop correct And Drag item 2 state equals Drop correct … (Continue through the rest of the drag items) 2. Show layer Incorrect when user clicks If Drag item 1 state does not equal Drop correct Or Drag item 2 state does not equal Drop correct … (Continue through the rest of the drag items) Drag Items For each drag item: 1. Change the item’s state to Drop Correct when it is dropped on the right drop target Change state of Drag Item 1 to Drop Correct when user drops Drag Item 1 on Drop Target 1 2. “Deselect” all other drag items when this drag item is selected (Change other drag items’ states to Normal, if they are currently selected) Change state of Drag Item 2 to Normal when user clicks Drag Item 1 If Drag Item 2 state is equal to Selected Change state of Drag Item 3 to Normal when user clicks Drag Item 1 If Drag Item 3 state is equal to Selected … (add this trigger for all other drag items on screen) 3. Change the item’s state to Drop Incorrect when it is dropped the wrong drop target(s) Change state of Drag Item 1 to Drop Incorrect when user drops Drag Item 1 on either Drop Target 2 or Drop Target 3 … (include all incorrect drop targets in the list) Drop Targets For each drop target: 1. Move the selected Drag Item along a motion path to the Drop Target when the user selects the drop target. NOTE: The move triggers MUST be before the state change triggers in the list Move Drag Item 1 on Motion Path* when the user clicks Drop Target 1 If Drag Item 1 state is equal to Selected * For the motion path, create a line motion path with start and end points in the center of the drop target. This will move the object to the correct location without showing movement on screen. Make sure to go into the path options and select “locked” for origin. This will ensure that no matter where on the slide the object starts from, it will move to the correct position with the trigger. Name the motion path something descriptive so you can identify it in the trigger list (ex: Drag 1 to Drop 1 Path). NOTE: When you create a motion path, Storyline automatically adds a trigger to the object to follow the motion path when the slide timeline starts. Make sure to go in and remove all of these triggers. … Make this trigger for all drag items on the slide. 2. Change the state of the corresponding Drag Item to Drop Correct, if the Drag Item is selected Change State of Drag Item 1 to Drop Correct when the user clicks Drop Item 1 if Drag Item 1 state is equal to Selected 3. Change state of the selected drag item to Drop Incorrect for all drag items that do not match with this drop target Change State of Drag Item 2 to Drop Incorrect when the user clicks Drop Item 1 if Drag Item 2 state is equal to Selected … Make this trigger for all remaining drag objects on the slide. CORRECT LAYER Elements Text box(es) Continue button Triggers Continue button Jump to next slide INCORRECT LAYER Elements Text box(es) Try Again button Triggers Try Again button Jump to slide (current slide) – this restarts the interaction on the slide base layer NOTE: Make sure the slide is set to “Reset to initial state” for the “when revisiting” selection in the slide properties. And there you have it! It looks like a lot, but once you've done it a time or two you can get the hang of it. Below is an example .story file of this interaction. It uses the same names as the instructions above so you can see how this all looks in a project.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!Custom Blocks - Text Scaling in Various Viewports.
Hi Community, I've recently been experimenting with the new custom block feature in Rise 360 to create more customized layouts. At times, I like to create text and image-oriented layouts to depict scenarios that are in alignment with my 17pt body text throughout my course. However, whenever I send my course modules for review, my subject matter experts express concern with the text sizes designed in the custom blocks. I am aware Rise 360 review is not 1:1 to its original editing view and the scaling also becomes more apparent when the contents are viewed on a mobile device and or tablet. Does anyone have any tips so I can maintain text sizes between custom blocks and rise block styles? I truly enjoy the new custom block feature, and I really want it to work for my course designs, but accessibility is a big priority. Any help or advice would be greatly appreciated. Thank you, Yedno Attached are screenshots for reference.
