I have an issue with a slide containing a video in an iFrame. Even though I set the iFrame as second in the reading order, Storyline still reads it last. Does anyone know how to force it to read in the set focus order? Our 508 team flagged this issue. We are trying Javascript injections to no avail (but we don't really know JS).
Hi there, is there any chance we can take a look at a stripped down example of this (removing any sensitive content). It haven't heard of this issue before and so may be something to do with the structure of your file. I would like to take a look if you can provide a file. Thanks.
Hello, I am helping Holly on this project, attached is a much-condensed version of the build we are working on (video has been swapped out but is still an iframe embed). As you can see in the focus order, the video is second under the page title, in theory, because the title is a text element, the video should be the first thing that gets focus when tabbing, but instead all of the other objects on the page get tabbing focus first.
Hi Gary, this looks to be an issue that Articulate will have to address. Looking at how it handles reading order, it adds elements to an HTML container with the class name "acc-shadow-dom". It does not add webobject, or embeded videos to this container, and therefore they are always read last.
This seems like it might be a bug that has been introduced as I'm sure I have used webobjects and embeded videos in the past and been able to set the correct reading focus, but I can see from the current HTML output, this is not going to be possible.
I attempted to do some manipulation with JavaScript by moving the video into the "acc-shadow-dom" container, but this is not an easy fix as the size and position of the video was changed due to a scaling property on the "acc-shadow-dom" container.
I have reported this as a bug to Articulate. Case number 00831827
Thank you, Sam, for taking the time to delve into our issue, uncover the core problem, and report it to Articulate! It's heartwarming to see community members go so far for their fellow colleagues. You are so kind to help us!
Sam, you mentioned a possible temp fix with JavaScript, I would be interested in taking a look at that script if possible? Were you manipulating the application code with it or adding it into the .story build as a script?
Hi Gary, I didn't say it would be a temp fix, it was just a failed experiment as the outcome was not good, due to the scaling that is added on the outer container changing the position and size of the video.
// Get the original element const originalVideo = document.querySelector('.slide-object-webobject'); // Clone the original element const clonedVideo = originalElement.cloneNode(true); // Remove the original element originalVideo.remove(); // Get the target element const targetProxy = document.querySelector('[data-acc-text="READ"]'); // Get the target element accessible version const targetElement = document.getElementById('acc-'+targetProxy.dataset.modelId); // Insert the cloned element before the target element targetElement.parentNode.insertBefore(clonedVideo, targetElement);
6 Replies
Hi there, is there any chance we can take a look at a stripped down example of this (removing any sensitive content). It haven't heard of this issue before and so may be something to do with the structure of your file. I would like to take a look if you can provide a file. Thanks.
Hello, I am helping Holly on this project, attached is a much-condensed version of the build we are working on (video has been swapped out but is still an iframe embed). As you can see in the focus order, the video is second under the page title, in theory, because the title is a text element, the video should be the first thing that gets focus when tabbing, but instead all of the other objects on the page get tabbing focus first.
Hi Gary, this looks to be an issue that Articulate will have to address. Looking at how it handles reading order, it adds elements to an HTML container with the class name "acc-shadow-dom". It does not add webobject, or embeded videos to this container, and therefore they are always read last.
This seems like it might be a bug that has been introduced as I'm sure I have used webobjects and embeded videos in the past and been able to set the correct reading focus, but I can see from the current HTML output, this is not going to be possible.
I attempted to do some manipulation with JavaScript by moving the video into the "acc-shadow-dom" container, but this is not an easy fix as the size and position of the video was changed due to a scaling property on the "acc-shadow-dom" container.
I have reported this as a bug to Articulate. Case number 00831827
Thank you, Sam, for taking the time to delve into our issue, uncover the core problem, and report it to Articulate! It's heartwarming to see community members go so far for their fellow colleagues. You are so kind to help us!
Sam, you mentioned a possible temp fix with JavaScript, I would be interested in taking a look at that script if possible? Were you manipulating the application code with it or adding it into the .story build as a script?
Hi Gary, I didn't say it would be a temp fix, it was just a failed experiment as the outcome was not good, due to the scaling that is added on the outer container changing the position and size of the video.
// Get the original elementconst originalVideo = document.querySelector('.slide-object-webobject');// Clone the original elementconst clonedVideo = originalElement.cloneNode(true);// Remove the original elementoriginalVideo.remove();// Get the target elementconst targetProxy = document.querySelector('[data-acc-text="READ"]');// Get the target element accessible versionconst targetElement = document.getElementById('acc-'+targetProxy.dataset.modelId);// Insert the cloned element before the target elementtargetElement.parentNode.insertBefore(clonedVideo, targetElement);