We have been testing some of our content with a JAWS screen reader and we noticed that when the screen reader encounters a text entry box nothing happens. This is no indication that it is a text entry box or what to do. Even if I add ALT text this is not read out. I am right in assuming that text entry boxes in Storyline 360 are not accessible? If so, are there any plans to fix this?
Can you have another look at a 'text entry box' not a text box. I know that text boxes work - that's basic. I wouldn't log something here for something that basic...
Got it, William. Thanks for the clarification and the push-back.
You are correct. This is an issue that has been reported to our team and I've added this conversation to the report as we track user impact and so that we can share any updates here with you.
We are beginning the process of reviewing all of our resources for ADA compliance, including the courses we created. Is there a comprehensive list of known problems for ADA compliance? It would be helpful to be able to plan for alternatives when these are known.
Thank you for reaching out and sharing the needs you are looking for! I am going to open up a Support Case on your behalf, to dive in a bit deeper here. Please be on the lookout for an email from Articulate Support!
We are trying to bring our courses up to WCAG 2.1 AA accessibility standards, and I noticed that nothing was being read when the screen reader encountered a text input field. Are there any updates on this post?
In Storyline 360 and Storyline 3, JAWS does not read the alternate text for a text entry field. Instead, JAWS will announce the placeholder text.
In the sample below, JAWS will not read "cherries and ice cream" and read, "type your text here."
This is still an open bug, and we'll update this discussion of any changes.
However, it sounds like you could be running into something else. What screen reader are you using? Also, is the tool reading the text entry field's placeholder text or nothing at all?
Thanks for checking in, and I'm sorry you came across this bug.
We're still monitoring its impact, where I've shared your voice in our report. We'll keep this discussion updated on any changes!
This idea from a community member is the only workaround we know of right now. This approach should let the learner know that they'll need to enter text in the entry field.
Let me know if there's anything else I can do. I'm happy to help!
Great question! A screen reader will first read the text in the Text Entry field. If you have the variable located on another slide that it will read the text that was typed into the Text Entry Field. You won't hear the variable unless that's what you typed in place of "Type your text here."
On a related note, I have an entry box for a number. Long instructions won’t fit in the field. Also, once you type in the field, the placeholder text doesn’t read anymore (so, if you were to go back to the field to edit it, you wouldn't know which field you are in). And putting instructions just before the field, which is the workaround mentioned above, does nothing if the user tabs between fields -- unless they are using arrow keys to move through pages, they'd never hear it. There doesn't seem to be an option anywhere to add a label (!) which is what we'd typically do on a website. Storyline -- PLEASE make alt text work in fields!!!! Right now, accessibility and usability is TANKED without it.
Is it just me? I cannot successfully use a numeric input field with JAWS.
I’m using the latest SL 360, JAWS, and Chrome.
We have a series of questions where the student is asked to input a number based on the question and a chart. The Focus Order is correct. With JAWS on, when I enter a page with an input field, the focus skips everything before the input field and snaps into it. The down and up keys do not allow me to access the question or chart.
I've noticed the same in your project. I found a simpler solution by using a Numeric Graded Question and customizing the Feedback Layers. This way, the learner can move through the Feedback Layers to see if the question was answered correctly or incorrectly. I've also tested this with NVDA, and it worked perfectly. I'll attach the updated file here. Let me know if you have any questions!
17 Replies
Hi William,
Thanks for reaching out and sharing what you are running into.
I just did a quick test and my text box is being read by JAWS. Here is a link.
Can you share a bit more information about your:
I'd be happy to take another look.
Can you have another look at a 'text entry box' not a text box. I know that text boxes work - that's basic. I wouldn't log something here for something that basic...
I apologize, William.
Yes. I took a look at a text entry box as well as the variable reference box to pair with it and JAWS is reading the content for me.
Take a look at slide 2 here and let me know what you are hearing (or not).
Can I verify that you are testing this in HTML5? I am actually having the problem in a FLASH version of a course.
Got it, William. Thanks for the clarification and the push-back.
You are correct. This is an issue that has been reported to our team and I've added this conversation to the report as we track user impact and so that we can share any updates here with you.
We are beginning the process of reviewing all of our resources for ADA compliance, including the courses we created. Is there a comprehensive list of known problems for ADA compliance? It would be helpful to be able to plan for alternatives when these are known.
Thanks!
Hi Kathy,
Thank you for reaching out and sharing the needs you are looking for! I am going to open up a Support Case on your behalf, to dive in a bit deeper here. Please be on the lookout for an email from Articulate Support!
Dear Tech Support,
We are trying to bring our courses up to WCAG 2.1 AA accessibility standards, and I noticed that nothing was being read when the screen reader encountered a text input field. Are there any updates on this post?
Thanks,
Shannon
Hi there, Shannon!
Issue Summary
In Storyline 360 and Storyline 3, JAWS does not read the alternate text for a text entry field. Instead, JAWS will announce the placeholder text.
In the sample below, JAWS will not read "cherries and ice cream" and read, "type your text here."
This is still an open bug, and we'll update this discussion of any changes.
However, it sounds like you could be running into something else. What screen reader are you using? Also, is the tool reading the text entry field's placeholder text or nothing at all?
Hello,
is there a follow up to this open bug?
Is there an alternate solution?
Hi Virgil,
Thanks for checking in, and I'm sorry you came across this bug.
We're still monitoring its impact, where I've shared your voice in our report. We'll keep this discussion updated on any changes!
This idea from a community member is the only workaround we know of right now. This approach should let the learner know that they'll need to enter text in the entry field.
Let me know if there's anything else I can do. I'm happy to help!
Thank you for your reply. I realize these things take time. Thank you for offering the workaround :)
Hello, is it possible for a screen reader to recognize a variable? Will it read %Title% or what the user types from the text entry field?
Thank you!
Hi Micaela!
Great question! A screen reader will first read the text in the Text Entry field. If you have the variable located on another slide that it will read the text that was typed into the Text Entry Field. You won't hear the variable unless that's what you typed in place of "Type your text here."
On a related note, I have an entry box for a number. Long instructions won’t fit in the field. Also, once you type in the field, the placeholder text doesn’t read anymore (so, if you were to go back to the field to edit it, you wouldn't know which field you are in). And putting instructions just before the field, which is the workaround mentioned above, does nothing if the user tabs between fields -- unless they are using arrow keys to move through pages, they'd never hear it. There doesn't seem to be an option anywhere to add a label (!) which is what we'd typically do on a website. Storyline -- PLEASE make alt text work in fields!!!! Right now, accessibility and usability is TANKED without it.
Is it just me? I cannot successfully use a numeric input field with JAWS.
I’m using the latest SL 360, JAWS, and Chrome.
We have a series of questions where the student is asked to input a number based on the question and a chart. The Focus Order is correct. With JAWS on, when I enter a page with an input field, the focus skips everything before the input field and snaps into it. The down and up keys do not allow me to access the question or chart.
Is this a bug? Please let me know.
I have included a test story file.
Hi Steven!
Thanks for reaching out! I'm happy to help.
I've noticed the same in your project. I found a simpler solution by using a Numeric Graded Question and customizing the Feedback Layers. This way, the learner can move through the Feedback Layers to see if the question was answered correctly or incorrectly. I've also tested this with NVDA, and it worked perfectly. I'll attach the updated file here. Let me know if you have any questions!