Blind and Visually Impaired Community
↑
6
↓
Screen-reader accessibility issue (self.Blind)
submitted by shuddering_1234
My team and I are working on a project that teaches coding to the visually impaired. We built the game in python using a speech to text module, and that works fine.
However, we have a website which contains lessons that users will read beforehand. I know you all know this but the Mac Screenreader tells you when you are on a button/when you are on text, but it doesn't read the text to you unless you highlight it. (We are using Wix, but it doesn't have what we want to make the site accessible).
Questions to the community:
1. Is there a way to get the Mac Screenreader to read text that you are hovering over
2. If not, what screenreader do you use to navigate through websites
Thank you for your input!
However, we have a website which contains lessons that users will read beforehand. I know you all know this but the Mac Screenreader tells you when you are on a button/when you are on text, but it doesn't read the text to you unless you highlight it. (We are using Wix, but it doesn't have what we want to make the site accessible).
Questions to the community:
1. Is there a way to get the Mac Screenreader to read text that you are hovering over
2. If not, what screenreader do you use to navigate through websites
Thank you for your input!
BlindGuyNW 8 points 4y ago
I think there's a few fundamental misunderstandings here. You're trying to use highlighting as a shorthand for getting the screen reader to read a specific bit of text, which in reality is totally not how blind people will actually use your site.
There are plenty of people, myself included, who use the Mac and Windows screen readers on a daily basis.
My suggestion to you is to outsource your screen reader testing to people who know how these things work. You might have to do a lot less work than you think, and you avoid running into weird dead ends like this one.
I would be happy to discuss further privately if you have specific questions.
There are plenty of people, myself included, who use the Mac and Windows screen readers on a daily basis.
My suggestion to you is to outsource your screen reader testing to people who know how these things work. You might have to do a lot less work than you think, and you avoid running into weird dead ends like this one.
I would be happy to discuss further privately if you have specific questions.
walling 1 points 4y ago
Here is an article explaining how to test your website using VoiceOver: https://webaim.org/articles/voiceover/
In general WebAIM have many interesting articles about web accessibility.
In general WebAIM have many interesting articles about web accessibility.
flameborn 0 points 4y ago
Hello,
I am not entirely sure what the problem is.
A screen reader user would not use the mouse to hover over elements, I assume you meant the mouse when you said hovering over the button.
Elements on a webpage are either navigated to via VoiceOver or other screen readers via the *tab* key, which is a standard browser feature, or via screen reader specific commands, e.g. *cmd+option+arrows*, or *cmd+option+ctrl+b*, if it is a button specifically.
Unless a screen reader user receives feedback about the physical position of any element on screen, navigating via the mouse does not make much sense.
It is an entirely different issue if your button is not a standard HTML button, but for example just a *div*. In this case screen readers would need to know that that particular item is a button. You can use ARIA for this.
If notifying the user about button text is important, for whatever reason, you can do this two ways: Most screen readers have a feature to read the text under the mouse, for example NVDA under Windows can do this nicely. The other option is to detect whether the mouse is positioned on an item and notify the user via ARIA alerts.
In theory, if you are focusing on screen readers, whatever you can navigate to either via *tab* or the VoiceOver commands on the Mac will speak and people should be able to interact with it. This of course depends on the control type as well, but generally it holds.
Hope this helps.
I am not entirely sure what the problem is.
A screen reader user would not use the mouse to hover over elements, I assume you meant the mouse when you said hovering over the button.
Elements on a webpage are either navigated to via VoiceOver or other screen readers via the *tab* key, which is a standard browser feature, or via screen reader specific commands, e.g. *cmd+option+arrows*, or *cmd+option+ctrl+b*, if it is a button specifically.
Unless a screen reader user receives feedback about the physical position of any element on screen, navigating via the mouse does not make much sense.
It is an entirely different issue if your button is not a standard HTML button, but for example just a *div*. In this case screen readers would need to know that that particular item is a button. You can use ARIA for this.
If notifying the user about button text is important, for whatever reason, you can do this two ways: Most screen readers have a feature to read the text under the mouse, for example NVDA under Windows can do this nicely. The other option is to detect whether the mouse is positioned on an item and notify the user via ARIA alerts.
In theory, if you are focusing on screen readers, whatever you can navigate to either via *tab* or the VoiceOver commands on the Mac will speak and people should be able to interact with it. This of course depends on the control type as well, but generally it holds.
Hope this helps.
This nonprofit website is run by volunteers.
Please contribute if you can. Thank you!
Our mission is to provide everyone with access to large-
scale community websites for the good of humanity.
Without ads, without tracking, without greed.
scale community websites for the good of humanity.
Without ads, without tracking, without greed.
©2023 HumbleCat Inc • HumbleCat is a 501(c)3 nonprofit based in Michigan, USA.