Screen Reader Accessibility for Button States
Apr 21, 2017
Hi there,
I'm having some trouble implementing accessibility for my Pick Many activities. Screen readers do not seem to recognize the difference between a Normal state and a Selected state of a button
I have a multiple choice question where the user can select more than one answer. I've made Normal state alt texts (Option 1, Option 2, Option 3, Option 4) and I've made Selected state alt texts (Option 1 Selected, Option 2 Selected, Option 3 Selected, Option 4 Selected). This way, a visually impaired user can know which answers he/she has already chosen before selecting the Next/Submit button.
It doesn't work though and the screen reader just reads the normal alt texts. Is there a solution around this? Thanks!
89 Replies
Hi, Susan.
I did a test with the alt text on two different states, and here's a short (less than 1 minute) recording of what I experience with JAWS.
Let me know if this answers your question!
Thanks for taking the time to do this. I was not clear in my comment. I meant AUTOMATICALLY with editing the alt text for the state. In other words, it does not seem to read the built in state such as "visited, or "selected"
Hello Susan!
That is correct. The states aren't automatically added in the alt text for each state. I'm happy to share this with my team in the form of a feature request. I'll update you in this discussion when it's added to our feature roadmap.
Hello,
The alt text in visited state is read, only if you have also changed the alt text in the normal state. It is a bit strange.
Hi there,
I'm not sure if this issue is still active but I am having trouble getting both JAWs and NVDA to recognize the visited state of buttons. It is my understanding that the reader should recognize and say "visited..." and then the name of the button (or something like that). Unfortunately, this is not happening. Is there a recommended workaround? Perhaps adding the word "visited" to the alt text for the visited state of each button. This is not ideal but I need a workaround in order to complete the course I am developing.
I welcome any and all suggestions.
Thanks for reading.
Hi Ephra,
I see that you were working with Renato, one of our Support Engineers, and he sent an email yesterday regarding the details of this issue.
We've reported it and promise to notify this discussion with any changes.
Sounds great; thanks so much.
Ephra
I'd like to revisit this issue and bring up something I've been experiencing. I'm able to get the screen reader to read the selected state - this was accomplished by copying the object, deleting it, and pasting it back in - but when when the slide is tabbed through, if users go backwards it reads also the normal state text.
https://360.articulate.com/review/content/34159c91-8e95-47fc-bd8c-cac3a3fd2dde/review
Hi Lauren!
Thank you for sharing the details of what you are experiencing.
I tested this on my end and had the same outcome as you did with NVDA reading the selected state and the normal state text when the slide is tabbed through.
As a follow-up question: which screen reader are you using?
I can add your experience to the bug we are working on and update you with any news in this thread!
Thank you for looking into this, Andrea. I am also using NVDA.
No problem, thank you Lauren!
Seems to be an issue with screen readers not being able to read the state of buttons - visited. Just did an update today for Storyline 360. Anyone else notice this happening?
We have version: 3.69.28997.0 and noticed this issue showing up as well. The visited states ALT text isn't being read out correctly by the screen readers (NVDA and JAWS). For buttons the visited state will be read out as "button" in NVDA or "unlabeled button" in JAWS.
The post about screen readers not recognizing the assigned state of shapes is 6 years old and still a problem. I am currently working on shapes that function as buttons with normal and visited states and screen readers are still not recognizing the states. Any chance of this being addressed finally? It makes the functionality inaccessible for some people.
Hi Heather (and anybody else this might help). A solution that can *sometimes* work, is to ensure that the default state of the element is defined in the Focus Order panel.
For example, the buttons Normal state text. I'm not sure why this has an impact, but it does. I can then have a custom state, and append the word "viewed" or "completed" to the ALT text in that state and it will be picked up by a screen reader.
There are still some sets of buttons that refuse to work, and I can't fathom why, as the set-up is identical.
Hi Heather,
I'm sorry you are having an issue with your shapes/buttons being read by your screen reader! You are experiencing a bug in the software that has already been reported. I'm going to add your voice to the report. If there's any news regarding this bug, this conversation will be updated.
Thanks for letting us know about this!