Forum Discussion
Inheritance of alt text by states in Storyline
Hi,
I am not sure if I am missing something, but it seems that alt text is not inherited by the states of items in Storyline. For example, if I create a radio button, its alt text is by default the name of the button type e.g. Radio button 3. If I want to make this radio button accessible by adding alt text, it seems like the only option is to edit the alt text for every state. I've tried doing it for just the normal and selected states, but that did not seem to work. NVDA still reads the button as "radio button 3" unless either all five states have the alt text or I delete the hover, down and disabled states. I have a project with 45 radio buttons in a matrix and having to edit the alt text for all five states means 225 editing steps...............
It seems to me that it would be much better for all states to inherit alt text from their parent normal state whenever the normal state text is updated - or at least for there to be a button in the alt text dialogue to propagate alt text to child states. I get that you can create an object and edit its alt text, create states for it and those states do inherit alt text, but that doesn't help with edits of the alt text or when you create an object that comes with ready made states.
Thanks!
Richard
Hi RichardPrince - I just performed some testing, and I'm finding that NVDA is announcing alt text during the preview. Last year, we implemented a new setting allowing screen reader support to be disabled. Can you check that the option is checked/enabled for you?
Screen reader support during preview is now optional. Turn it on in the Storyline Options window
- MathNotermans-9Community Member
You are quite correct. States get their own acc-names what is not good. In the advanced javascript API you can set a state by javascript. It might be good if that would be fixed too. ZevanRosser is this still actuall with the new Js API ? Whats the reason for it? I dont see any accessibility requirements for it. Could it be fixed in a way Richard suggests?
@RichardPrince the reason for this (at least with a radio button) is that we use a real html radio button element in this scenario so that screen readers behave traditionally. There may be a way to get the behavior that you want, but we'd need to see your story file.
As far as states for normal buttons etc... we'd again want to get a story file and log an issue with support. 508/Accessibility is a very complex area.
MathNotermans-9 This doesn't have anything to do with the js api thankfully :D- RichardPrinceCommunity Member
Hi Zevan, well, having sat yesterday evening editing all of the states in all of the radio buttons, my story file no-longer has this issue, because I have changed all 225 alt texts! I played around with it again today, and seem to be able to get the alt text working by editing just the selected and normal states of the buttons (I had thought the screen reader was picking up the hover state alt text). This means there is a work around:
- Create radio buttons but do not put them into groups
- Set all buttons to normal and then edit the alt text in Focus Order
- Set all buttons to selected and then edit the alt text in Focus Order
- Make button groups
This only requires twice as much work as if the radio button states automatically took their alt text from the normal state, but at least it is not 5x as much!
I probably would have found this work around much sooner, but for the fact that testing Storyline output with NVDA is so time consuming. As I am sure you are aware, the preview window does not pass any alt text to screen readers, so my work flow has necessitated uploading each attempt to Rise, and testing there. Any chance Storyline could get a fix to make accessibility easier to check - given it is a legal requirement that the output I generate from Storyline is accessible, I would have hoped that Articulate would be trying to find ways to make checking accessibility easier?
Best wishes
Richard