Forum Discussion
Screen Reader accessing layers that aren't active
- 9 months ago
Hi BryanVarner this is a Storyline bug and will hopefully be fixed quickly, as it is a serious accessibility bug. The table element should behave as all other elements do. I'm not sure why it is missing the aria-hidden attribute.
A hotfix solution for this would require JavaScript. I might be able to help you out if you are potentially delivering this before a proper fix comes through.
If you are interested, here's some script.
Add this to the main timeline and execute JavaScript on timeline start:
rmLocalHideTable = function(hidden, attempt) { let tries = attempt || 0; const observations = document.querySelector('table[aria-label="Table with 3 columns and 12 rows"]'); // table not found, try again if(observations === null) { if(tries !== 10) { tries += 1; setTimeout(function(){ rmLocalHideTable(hidden, tries); },100); } }else{ // table found, set aria-hidden attribute observations.setAttribute('aria-hidden',hidden); } } window.rmHideTable = function(hidden, attempt) { // add delay before running to ensure any // conflicting scripts have time to run first setTimeout(function(){ rmLocalHideTable(hidden, attempt); },500); }You can then call the following JavaScript functions to show/hide the table for screen readers:
Whenever the Data & Observations Layer layer opens, run this function:
// Make available for screen readers window.rmHideTable(false);Whenever the Data & Observations Layer layer is hidden, run this function:
// Hide from screen readers window.rmHideTable(true);I have added to your file as an example.
Hi StevenBenassi and BryanVarner
I can confirm I have been able to replicate the behaviour and have identified the issue.
The layer that appears to be the problem is labelled Data & Observations Layer.
After inspecting the HTML I can see that all elements within the layer, when the layer is hidden, correctly have the aria-hidden=true attribute applied, apart from the table.
The table does not have the aria-hidden attribute defined at all, therefore this element remains visible to screen readers even when visually hidden.
Interesting, thanks for figuring that out. Is there a solution for this or is that how tables typically behave in Articulate?
- SamHill9 months agoSuper Hero
Hi BryanVarner this is a Storyline bug and will hopefully be fixed quickly, as it is a serious accessibility bug. The table element should behave as all other elements do. I'm not sure why it is missing the aria-hidden attribute.
A hotfix solution for this would require JavaScript. I might be able to help you out if you are potentially delivering this before a proper fix comes through.
If you are interested, here's some script.
Add this to the main timeline and execute JavaScript on timeline start:
rmLocalHideTable = function(hidden, attempt) { let tries = attempt || 0; const observations = document.querySelector('table[aria-label="Table with 3 columns and 12 rows"]'); // table not found, try again if(observations === null) { if(tries !== 10) { tries += 1; setTimeout(function(){ rmLocalHideTable(hidden, tries); },100); } }else{ // table found, set aria-hidden attribute observations.setAttribute('aria-hidden',hidden); } } window.rmHideTable = function(hidden, attempt) { // add delay before running to ensure any // conflicting scripts have time to run first setTimeout(function(){ rmLocalHideTable(hidden, attempt); },500); }You can then call the following JavaScript functions to show/hide the table for screen readers:
Whenever the Data & Observations Layer layer opens, run this function:
// Make available for screen readers window.rmHideTable(false);Whenever the Data & Observations Layer layer is hidden, run this function:
// Hide from screen readers window.rmHideTable(true);I have added to your file as an example.
- BryanVarner9 months agoCommunity Member
Amazing Sam, thank you!
StevenBenassi Students will be doing this activity in April. Any insight you could provide into the timeline for this bug being fixed would be really appreciated!- StevenBenassi9 months agoStaff
Hi BryanVarner!
Thanks for following up!
I noticed you've connected with my colleague Robert, through your support case. It looks like he replied to your e-mail with some follow-up questions as well. I've updated Robert with the additional insight Sam shared, to assist while he tests your file.
We're committed to continually improving the accessibility features of our apps. If we confirm this behavior is related to a bug in Storyline, we'll work as a team to prioritize the problem. Thank you for your patience. I'm sorry if this has been slowing you down!
- StevenBenassi9 months agoStaff
Hi SamHill!
This is super helpful, thank you for sharing!
Related Content
- 24 days ago