I know this subject is somewhat overused, but I have some thoughts that I can't help but want to discusse with the people in here.
while browsing a topic similar to this I saw someone suggesting we make a long artical detailing all the bugs and problems with voiceover on macos, then we could go and check/cross mark them if they are solved so people can see stuff in real time and we could make a giant wave where people politely ask apple accessibility to take a look at the post
my curiosity is, has something been done about this? IS there somehting like that somewhere?
the other point that I've been pondering, making different screen readers.
I've been going in denial mode that we don't need it, the company is going to deal with it, but honestly.
we all know that is not true, we'll never be nearly as satisfied as we would be with say, NVDA on windows, yes, NVDA still has some bugs/complaints, like any software in the world naturally would, but it became literally a desktop accessibility standard for how to do things right, while macos is the exact opisite.
like yes, I agree with the people that comparing the two is not a good idea and they are both different, but lets be honest with ourselves, how much is that being honest and how much of that is simply not wanting to admit that it's not actually ideal?
like, I got used to voiceover, and honestly? I don't think I would mind it too much, it's somewhat slow in some places while it's fast in others, it's a different way to navigate ui, but when something slightly inconvenient happens to have a lot of bugs, it starts getting somewhat tiring.
I don't need to put a monologue about what issues voiceover does and doesn't have because I think everyone on this forum already mastered an replayed that game, so lets explore something else.
making something new.
it was brot up a few times, I saw that, and in fact, there was an attempt that was ultimately discontinued through vosh, the developer not to blame of course, but I'm still wondering about this.
I'm a developer myself. And I have ok experience. Not a newbie who simply asked AI 5 questions and can write simple ui appps/games, but someone whoo genuinely knows what I'm talking about. This isn't bragging, but I know that a lot of people nowadays underestamait what a developer means and simply say they are after learning the absolute basics, which isn't exactly wrong, but I know that people might dismiss me instantly if I did so.
anyway, a bit of an off-topic rant, but now that's out of the way.
I am curious, were there any confirmed facts as for whether making a screen reader other than voiceover being impossible? I believe vosh was relatively in the alpha stage and had extremely basic navigation functionality so I am not sure if the developer stopped because it was impossible to go further, or the developer got busy with life.
and I will admit, I am hoping perhaps the interest of some other developer(S) Might get grabbed, since I refuse to believe I'm the only one who's getting exausted by how utterly tiring voiceover it is, and as a developer, I use text editing a lot, and require thigns such as caret navigation or normal web navigation to be reliable and consistent, but voiceover didn't give me that experience at all. And while I acknowledge the effort by the apple accessibility team, and unlike others I know that some effort is being put in because some of my personal bug reports/finding were solved, however, I believe it will take decades for voiceover to become ideal, because we all know that voiceover fixes one problem and introduces 3 new ones.
what do you guy think, and sorry if this post was overly long.
By emperor limitless, 30 April, 2025
Forum
macOS and Mac Apps
Comments
Web navigation
I find that using Tab, Shift-Tab and other browser navigation commands rather than VoiceOver commands makes amazon.com much easier to work with in Safari. Some Web applications are similar in this regard.
I'm largely satisfied with the Web browsing experience on macOS with Voiceover and Safari (no desire to use Windows instead). However, as discussed earlier in this thread, Apple hasn't addressed the underlying issues responsible for applications' becoming unresponsive, including Web browsers. The incidence of "Safari not responding" messages has greatly reduced in recent macOS releases, but the underlying phenomenon (possibly threads waiting for API calls to return that never do) still exists.
If an application becomes unresponsive, it's still possible to switch to other applications and to use them with VoiceOver. This suggests VO is using multiple threads to interact with different running applications - again, not solving the problem, but mitigating the effects.
Browsing Amazon.
I use Firefox, so YMMV. I find that if you search for a product and want to get to the results and have heading nav and such mostly work, it helps to scroll past all the junk at the top. So what I usually do is hit 'h' a couple of times in single key quick nav, get to maybe "hide keyboard shortcuts" or such, and then just hold VO-right until you get past search at least.
Re: How to focus progress bar?
When downloading something in Safari, after clicking the download link, and allowing the download if this is your first time downloading from that website, you can reveal the Downloads window by choosing View > Show downloads (or pressing Command-Option-L). In this window, interact with the table, and then interact with the item being downloaded. Here, you should find a progress indicator and status text for the item.
By default, VoiceOver might not automatically speak when the focused item, like the status text or progress indicator, is updated, but this can be changed in VoiceOver Utility > Verbosity > Announcements. In addition, settings for what to do when status text changes can be changed from anywhere in macOS by pressing VO-V, and choosing an option from the "When status changes" menu.
HTH
Safari not responding
I did actually experience the infamous SNR bug while developing Vosh on macOS 14, and it was definitely not a consumer-side accessibility thing, so it does not have anything to do with VoiceOver using or not multiple threads to do accessibility, which it likely doesn't, because as I mentioned earlier, the consumer-side of the accessibility infrastructure is not thread-safe.
What I experienced back then was that some accessibility connections, if we can call them that, would randomly either not get replies from WebKit or would fail immediately as if they had timed out but without actually letting the configured time elapse. This was also accompanied by browser instability, so if all the accessibility elements for the browser were locally destroyed and recreated again, the browser would resume working but eventually would grind to a halt. At one point I even experienced SNR on Vosh while VoiceOver was working normally at exactly the same time.
While Apple definitely attempted to tackle the problem on macOS 15, I suspect that their attempt was yet another workaround, because what I observe now is that after browsing some websites, VoiceOver's responsiveness sometimes begins slowing down to a point that the time it takes between issuing a command and getting feedback exceeds 3 seconds, until eventually SNR briefly appears and then the system does something to reset the accessibility infrastructure or whatever, and the feedback delay goes back to normal.
Valuable explanation
That's a very helpful explanation - thank you. Perhaps using accessibility API debugging tools, if they're publicly available from Apple, would assist in bug reporting. Can the community arrange for someone who knows how to track down problematic API interactions to reproduce bugs and report the technical details? This would (I hope) bypass the first step Apple would need to carry out in attempting to reproduce bugs and to identify the cause. I know this community shouldn't have to do what I'm suggesting. Writing good bug reports should be enough, but there's also potential value in demonstrating the underlying technical causes - at least in some cases.
Of course, if Apple doesn't make a monitoring tool available that can show API access, then this won't be possible - potentially illegal as well.