I am
testing the accessibility features on a storyline file using JAWs 14.0 demo
version. I am using IE 10 to open the published HTML file. The JAWs reader is
not reading my ALT text for my images. It is reading the file name in the
timeline instead. I have selected to have the object visible to accessibility
tools and have entered a description. What could be causing the JAWs reader to
ignore my description and just read the file name?
It sounds like you've had things set up correctly in terms of selecting that the object is visible to accessibility tools, and including text within the Alt text box below:
If you'd like us to take a look at your .story file, please share it here.
I see the same thing when my image is used like a button. If no trigger is associated with the image, Jaws reads the alt text. When a trigger has been added to show a layer when the user clicks on the image, the filename of the image is being read by Jaws.
I see the same thing when my image is used like a button. If no trigger is associated with the image, Jaws reads the alt text. When a trigger has been added to show a layer when the user clicks on the image, the filename of the image is being read by Jaws.
Hi Kit, I think this may be the case ... thanks for the feedback. This has been very helpful.
Hi Sandy, this is due to the Storyline bug which I have described here. The video in my post demonstrates why this is happening and shows you a workaround for it. Essentially, you'll have to create all your buttons again from scratch! This is a ridiculous and tedious workaround (especially if you have many buttons that you wish to duplicate) which is why I am still hoping that the Articulate team will address this bug in an update someday. Hope this helps, and it would be great if you could submit this as a new support case, as that *may* prompt the team to address this bug as a priority. Thanks!
Hi. I have the same issue. JAWS is not reading my texts right. Let's say I have 3 text boxes. It reads all three text boxes the same way (usually the text from the first text box). For example, if the first text box reads: "This is a dog", the next two text boxes will read "This is a dog."
With the issue on the data entry button, I followed Kuriko's suggestion above but it still did not work for me.
What is going on? I've spent the whole morning building just one activity and until now, the accessibility features I built are not working. I am pressed for time. Help!
Hi Tina! Any chance you can share your project file with me? I am very familiar with JAWS and accessibility in Storyline, so I should be able to help you out. You can either add your file in a reply to this message, or if you prefer, upload the file here.
Can you identify what version of JAWS you are using? Thanks!
I was having a similar problem, though not sure how similar my situation is: I was using images as buttons, giving them multiple states and applying triggers to them. NVDA was reading my image file names instead of the alt tags I'd given the images. I was able to resolve the issue by applying the alt tag not only to the image, but also, specifically, to the instance of the image within its Normal state. Also noticing that if I have separate alt tags on the image and the image's normal state, the normal state's alt tag is what gets read.
The answer from Articulate will likely be 'No'. But the good news is that you don't have to worry about whether or not NVDA is supported by Articulate because from my experience any Storyline bugs that have occurred in NVDA have also occurred in JAWS. So I don't accept 'We don't support NVDA' as an answer. I will always ask them to actually test the issue in JAWS and to confirm if the same behaviour occurs. In my experience, it always does.
In relation to Douglas' post, I can confirm that this issue definitely occurs in Storyline 2, whether you're using NVDA or JAWS. The Articulate team have no intention at present to fix this bug in Storyline 2. Instead they want you to pay to upgrade to Storyline 3 in order to fix the bug. This is quite odd, as most software companies fix bugs in their software as free updates.
I haven't tested Storyline 3, so I can't confirm whether it has fixed the bug and whether this is the case in both NVDA and JAWS. Personally I don't have the time to bother testing it in the free trial myself... Since this bug has been around for 4 years, I'm now very accustomed to using the dodgy workarounds that we had to devise to overcome the issue (such as the nifty one that Douglas mentioned). But if you do have time to test Storyline 3, let me know how you go with NVDA.
Bummer: not only does this bug still exist in Storyline 3, but it appears now to extend to actual buttons.
Was building a project in Storyline 2 and upgraded the project file to Storyline 3 to take advantage of Storyline 3-produced projects not having a tab navigation bug I was encountering with S2-produced projects. Found that after upgrading the project to S3, the buttons within it were now exhibiting the same bug I reported earlier in this thread regarding multi-state image alt text in S2. Since I don't think my previous assessment of that bug was fully accurate, I'd now describe it as:
For images in S2 that have more than one state AND a different alt text for the image (outside of Edit States) and the Normal state (within Edit States), the Normal state alt text is what will be read by the screen reader; if the Normal state's alt text is blank (but detectable), the image file name will be read by the screen reader. The fix for this bug is to give the Normal state the desired alt text. The best method, I found, for applying this fix is to give the image the desired alt text BEFORE creating any additional states; that way all additional states will automatically be given that alt text (however, then if you want to change the alt text, you have to do so within the Normal state).
In S2, this bug did not occur with buttons. The button's (outside of Edit States) alt text was being read, even though the button's Normal state alt text was blank.
I've found in S3 that the button's Normal state alt text is what is (initially*) read by the screen reader AND that if the Normal state's alt text is left blank, S3 will automatically populate that field with the button's original Timeline designation +1. E.g., when first created, a button appears in the Timeline as Button 1. Its Normal state alt text is automatically populated as Button 2 (even if you delete the alt text, it will be re-populated as Button 2). All other button states appear to have the auto-populated alt text of Button original # + 2. E.g., Button 1's hover state has Button 3 as its auto-populated alt text.
*Other observations:
In S3, if a button has different alt text for its Normal state and outside of Edit States:
If you tab navigate to the button, its Normal state alt text will be read until you hit enter or click on it, at which point its outside of Edit States alt text will be read.
If you hover over it, its outside of Edit States alt text will be read.
In S3 and S2, if an image has different alt text for its Normal state and outside of Edit States, its Normal state alt text will always be read, even after you hit enter on it.
In S2, if a button has different alt text for its Normal state and outside of Edit States, its outside of Edit States alt text will always be read.
I'm using SL360 latest version, JAWS version for testing.
For Multiple choice questions, Jaws is reading the option in normal state (no radio button selected) but once the radio button is selected it won't announce it is selected.
I saw there was a bug logged for SL3 but is there one also logged for SL360 and is there a workaround? I'm on a deadline and have 3 modules all with MC quiz assessments that need to be accessible - HELP...
I am also encountering problems with tabbing and check boxes. Normally, when you tab to a checkbox or button, you need to press enter in order to trigger the action.
In 2 of my current projects, on some screens when you tab to the check box, nothing will happen until the enter key is pressed - this is expected behavior. On other slides, and this is all within the same project, just tabbing to the check box will activate it. I've deleted check boxes and recreated them but can't get rid of the problem.
Any suggestions? I've spent way too much time trying to fix the problem but it's still occurring and these were due yesterday.
The projects were created in Storyline 360 at the very end of November, 2017. And the software is kept up to date. I'll send the .story file to the link you provided. Thanks!
We are still having this issue, we use Storyline 360 and JAWS as a reader. It is reading the image file name instead of the alt tag when used as a button. The work around that we had to do was to delete the visibility of all the images, the triggers, and set buttons set back to none. Then we followed Jonathan's advice of putting "an invisible rectangle on top of a real button that has the triggers you originally had on the real button underneath it and remove accessibility from the real button and add the ALT text to what is now essentially an invisible button on top of your real button." This is very tedious work and let me tell you that our team is not happy of having to have to redo so much work because this feature is not working correctly and it has been a known issue for over a year. Please get this bug fixed!
Maria, just to clarify, it sounds like the alt text that is being read is what is contained in the Normal state (when using the States tab), rather than what you've assigned by clicking on the image directly on the slide stage. Is that accurate?
Here's a look at what I mean (using a standard button rather than an image):
I'm sorry this behavior is impacting your workflow - I know it takes valuable time to edit the alt text like that. This particular issue has been on our radar for a few months, and we're working to prioritize it.
You're in the right place to be updated when we have new information to share.
This is really frustrating guys. We are a university and are moving towards making all our online learning content accessible. This kind of behavior where you cannot reliably make content readable by a screen reader might mean that eventually we'll need to seek out another tool. Please do something about this.
I'm truly sorry for the frustration that this is causing you, and our team knows how important accessibility is. We've released a few fixes for the items in this discussion in the past couple updates of Storyline 360. For example, the following items were recently fixed:
JAWS screen readers wouldn't announce the active player tab.
There were some keyboard navigation issues, such as an incorrect tab order for objects on slide layers.
Alt text on object's other states is not read by JAWS
If you're using Storyline 3, those same fixes will be available in the next update (release date TBD) and we'll let folks know as soon as that's ready!
If you've hit any other roadblocks, we definitely want to know about them! Can you share details and any examples (screen recordings, .story files, etc.) with our Support team by uploading at this link?
I am experiencing the issue whereby JAWS is reading the alt txt within the button's state, not the Alt Text signify in the Tab Order screen. Just as Crytal's video shows above.
49 Replies
Hi Sandy and welcome to Heroes!
It sounds like you've had things set up correctly in terms of selecting that the object is visible to accessibility tools, and including text within the Alt text box below:
If you'd like us to take a look at your .story file, please share it here.
I see the same thing when my image is used like a button. If no trigger is associated with the image, Jaws reads the alt text. When a trigger has been added to show a layer when the user clicks on the image, the filename of the image is being read by Jaws.
Hi Kit, I think this may be the case ... thanks for the feedback. This has been very helpful.
Hi Sandy, this is due to the Storyline bug which I have described here. The video in my post demonstrates why this is happening and shows you a workaround for it. Essentially, you'll have to create all your buttons again from scratch! This is a ridiculous and tedious workaround (especially if you have many buttons that you wish to duplicate) which is why I am still hoping that the Articulate team will address this bug in an update someday. Hope this helps, and it would be great if you could submit this as a new support case, as that *may* prompt the team to address this bug as a priority. Thanks!
Hi. I have the same issue. JAWS is not reading my texts right. Let's say I have 3 text boxes. It reads all three text boxes the same way (usually the text from the first text box). For example, if the first text box reads: "This is a dog", the next two text boxes will read "This is a dog."
With the issue on the data entry button, I followed Kuriko's suggestion above but it still did not work for me.
What is going on? I've spent the whole morning building just one activity and until now, the accessibility features I built are not working. I am pressed for time. Help!
Hi Tina! Any chance you can share your project file with me? I am very familiar with JAWS and accessibility in Storyline, so I should be able to help you out. You can either add your file in a reply to this message, or if you prefer, upload the file here.
Can you identify what version of JAWS you are using? Thanks!
Hi Tina, how did you go with this? Was Mat able to identify the issue? Let me know if I can help.
I was having a similar problem, though not sure how similar my situation is: I was using images as buttons, giving them multiple states and applying triggers to them. NVDA was reading my image file names instead of the alt tags I'd given the images. I was able to resolve the issue by applying the alt tag not only to the image, but also, specifically, to the instance of the image within its Normal state. Also noticing that if I have separate alt tags on the image and the image's normal state, the normal state's alt tag is what gets read.
Hi Douglas,
What version of Storyline are you using? Although many aspects of the course may work with the NVDA reader it's not officially supported at this time.
If you're using Storyline 360 our supported option are listed here.
Hi Ashley, are there any plans to support the NVDA reader? Thanks!
Hi Janet,
The answer from Articulate will likely be 'No'. But the good news is that you don't have to worry about whether or not NVDA is supported by Articulate because from my experience any Storyline bugs that have occurred in NVDA have also occurred in JAWS. So I don't accept 'We don't support NVDA' as an answer. I will always ask them to actually test the issue in JAWS and to confirm if the same behaviour occurs. In my experience, it always does.
In relation to Douglas' post, I can confirm that this issue definitely occurs in Storyline 2, whether you're using NVDA or JAWS. The Articulate team have no intention at present to fix this bug in Storyline 2. Instead they want you to pay to upgrade to Storyline 3 in order to fix the bug. This is quite odd, as most software companies fix bugs in their software as free updates.
I haven't tested Storyline 3, so I can't confirm whether it has fixed the bug and whether this is the case in both NVDA and JAWS. Personally I don't have the time to bother testing it in the free trial myself... Since this bug has been around for 4 years, I'm now very accustomed to using the dodgy workarounds that we had to devise to overcome the issue (such as the nifty one that Douglas mentioned). But if you do have time to test Storyline 3, let me know how you go with NVDA.
Bummer: not only does this bug still exist in Storyline 3, but it appears now to extend to actual buttons.
Was building a project in Storyline 2 and upgraded the project file to Storyline 3 to take advantage of Storyline 3-produced projects not having a tab navigation bug I was encountering with S2-produced projects. Found that after upgrading the project to S3, the buttons within it were now exhibiting the same bug I reported earlier in this thread regarding multi-state image alt text in S2. Since I don't think my previous assessment of that bug was fully accurate, I'd now describe it as:
For images in S2 that have more than one state AND a different alt text for the image (outside of Edit States) and the Normal state (within Edit States), the Normal state alt text is what will be read by the screen reader; if the Normal state's alt text is blank (but detectable), the image file name will be read by the screen reader. The fix for this bug is to give the Normal state the desired alt text. The best method, I found, for applying this fix is to give the image the desired alt text BEFORE creating any additional states; that way all additional states will automatically be given that alt text (however, then if you want to change the alt text, you have to do so within the Normal state).
In S2, this bug did not occur with buttons. The button's (outside of Edit States) alt text was being read, even though the button's Normal state alt text was blank.
I've found in S3 that the button's Normal state alt text is what is (initially*) read by the screen reader AND that if the Normal state's alt text is left blank, S3 will automatically populate that field with the button's original Timeline designation +1. E.g., when first created, a button appears in the Timeline as Button 1. Its Normal state alt text is automatically populated as Button 2 (even if you delete the alt text, it will be re-populated as Button 2). All other button states appear to have the auto-populated alt text of Button original # + 2. E.g., Button 1's hover state has Button 3 as its auto-populated alt text.
*Other observations:
In S3, if a button has different alt text for its Normal state and outside of Edit States:
In S3 and S2, if an image has different alt text for its Normal state and outside of Edit States, its Normal state alt text will always be read, even after you hit enter on it.
In S2, if a button has different alt text for its Normal state and outside of Edit States, its outside of Edit States alt text will always be read.
Hi Mat
I'm using SL360 latest version, JAWS version for testing.
For Multiple choice questions, Jaws is reading the option in normal state (no radio button selected) but once the radio button is selected it won't announce it is selected.
I saw there was a bug logged for SL3 but is there one also logged for SL360 and is there a workaround? I'm on a deadline and have 3 modules all with MC quiz assessments that need to be accessible - HELP...
I am also encountering problems with tabbing and check boxes. Normally, when you tab to a checkbox or button, you need to press enter in order to trigger the action.
In 2 of my current projects, on some screens when you tab to the check box, nothing will happen until the enter key is pressed - this is expected behavior. On other slides, and this is all within the same project, just tabbing to the check box will activate it. I've deleted check boxes and recreated them but can't get rid of the problem.
Any suggestions? I've spent way too much time trying to fix the problem but it's still occurring and these were due yesterday.
Hi Janet! Your issue sounds like it may be a bit different than Wendy's and I know that she's working with Alyssa here.
It sounds like you are currently working on all of these projects, so they are developed with the same version/update and no variance?
Would you be able to share your .story file with our team here so that we can take a look Janet?
Hi Leslie,
The projects were created in Storyline 360 at the very end of November, 2017. And the software is kept up to date. I'll send the .story file to the link you provided. Thanks!
Hi Leslie, I submitted a support case. Thanks!
Thanks Janet :)
We are still having this issue, we use Storyline 360 and JAWS as a reader. It is reading the image file name instead of the alt tag when used as a button. The work around that we had to do was to delete the visibility of all the images, the triggers, and set buttons set back to none. Then we followed Jonathan's advice of putting "an invisible rectangle on top of a real button that has the triggers you originally had on the real button underneath it and remove accessibility from the real button and add the ALT text to what is now essentially an invisible button on top of your real button." This is very tedious work and let me tell you that our team is not happy of having to have to redo so much work because this feature is not working correctly and it has been a known issue for over a year. Please get this bug fixed!
Maria, just to clarify, it sounds like the alt text that is being read is what is contained in the Normal state (when using the States tab), rather than what you've assigned by clicking on the image directly on the slide stage. Is that accurate?
Here's a look at what I mean (using a standard button rather than an image):
I'm sorry this behavior is impacting your workflow - I know it takes valuable time to edit the alt text like that. This particular issue has been on our radar for a few months, and we're working to prioritize it.
You're in the right place to be updated when we have new information to share.
This is really frustrating guys. We are a university and are moving towards making all our online learning content accessible. This kind of behavior where you cannot reliably make content readable by a screen reader might mean that eventually we'll need to seek out another tool. Please do something about this.
Hi Carolyn,
I'm truly sorry for the frustration that this is causing you, and our team knows how important accessibility is. We've released a few fixes for the items in this discussion in the past couple updates of Storyline 360. For example, the following items were recently fixed:
If you're using Storyline 3, those same fixes will be available in the next update (release date TBD) and we'll let folks know as soon as that's ready!
If you've hit any other roadblocks, we definitely want to know about them! Can you share details and any examples (screen recordings, .story files, etc.) with our Support team by uploading at this link?
Hello,
Using latest version of storyline 360 and jaws
I am experiencing the issue whereby JAWS is reading the alt txt within the button's state, not the Alt Text signify in the Tab Order screen. Just as Crytal's video shows above.
Thanks for confirming Jason.
This thread is attached to that report and we will update you here when we can.
Thank you for the head's up, Leslie. It is definitely an issue.