Issues with dock and voiceover on Mac OS 15.3

Reported already and known since the early beta of 15.3 if not 15.2. I am impressed by the cleanliness of your report. You can do vo escape to return to the previous app#context but for the focus to be back you ideally want to do cmd tab to navigate between apps.

Nice job on the bug report. You were clear and concise. You gave clear and good examples. You stated expected result and actual results. That should help. You may in some cases have to submit other files but if you need to do so apple accessibility will let you know. again nice job!!!!!!!!!

I have a couple of suggestions.
First, has anyone tried pressing VO plus D a second time, once they are already in the dock? I am asking this with the consideration that on iOS if you have a gesture to get to the status bar, or you use BSI to get to the status bar, and use either gesture or command a second time, it gets you back to your last position. I am just wondering if VO plus D a second time might do the same thing in the latest macOS? Apologies I cannot test this out myself, as my old MacBook Pro is locked in at macOS 12 (Monterey). And there, I don't have these issues.
Secondly, can you interact with text in Safari to navigate character by character/word by word? Just asking here. 🙂

I also am aware of users reporting issues with the Dock, but as I very rarely use it, I don't know exactly when these issues were introduced or what the expected behavior is in all cases. However, as an alternative to the Dock, I use VoiceOver commands to open my most-used apps, which works flawlessly for me. You can configure this in VoiceOver Utility > Commands. For more detailed information and an audio demonstration of how this is done, check out the AppleVis podcast episode "A Demonstration and Walkthrough of VoiceOver Command Customization on macOS."

HTH

Here are some reading tips for you:
1. Reading by Sentence: VO + S
2. Reading by Line: VO + L
3. Reading by Word: VO + W
4. Reading by Character: VO + C

Note that these will read the attribute that VO has focus on. In other words, if VO is on the word Apple, it will read characters, words, etc where that word is, because that is where VO is focused.

Below is a guide where I got my info.
https://support.apple.com/guide/voiceover/text-commands-cpvokys06/10/mac/15.0

HTH.

For line specifically, note that words and characters won't follow like on ios but you can add the line option in the web rotor.

Apologies, I have very little experience with chrome on macOS. The normal line by line reading is done by VO plus up/down arrow, but as has been mentioned already, that does not seem to work on Google Chrome.

My point exactly.
This company since I've purchased the mac has made me uncomfortable on the web while it's completely their fault. Things with amazing accessibility like the desmos calculator are horrible just because VO devs randomly decided to add a disturbing, hardcoded sound for a specific aria event I don't have enough knowledge to name but which ruins the experience on everything, plus VO being so sluggish in just an empty new document inside vscode because of VO skill issues. Whenever I have to do serious web stuff I'd always choose Windows. I can barely survive with google docs when I really have to but...
Before you yell at me, yes, most if not everything I report here has already been reported to Apple in feedback as well a11y@apple. Time will tell if this was worth it. Even then for some very specific things I'd rather choose my mac than windows and recently I've been using my mac much much more than I ever expected so... Like who would have ever seen the plot twist of math content being better on the mac than with nvda on windows? See their latest release notes. I thought that something was wrong with windows, but no. Plus that thing with the latest bug patched has never been more stable. interaction is messy but at least it does work.
Sorry if it's off topic.
PS: those who no longer have a mac should be advised to triple check the latest non existant documented pile of bugs to avoid spreading misinformation in an already ugly messy software that is Voiceover, please. I started on ventura and even then vo up/down arrow was never working inside any browser safari or chrome, just in preview. If it did earlier then... This is just apple.

Yeah this is terrible. That's why when possible I'd always interact with the text which is indeed random on the web no matter which browser you choose.
I come from a windows background and in my 1.5 years I've developed horrible 10x workarounds to be able to sincerely smile when using the mac, if you ever need help don't hesitate to dm me. I'd also recommend renaming this topic as something like bugs encountered for a new mac user 2025 edition (half joking here) which might help other see the accessibility landscape for a newcomer in 2025, but it's up to you. Just saying that cause we left the dock problem since a while already.
HTH

With f7 you get chrome own keyboard cursor something that most windows users don't even know cause there sr parse in a virtual buffer or something but it don't sync with VO even when routing the cursors together with vo. There are clever workarounds but very slow. For example I had the orca mailing list in freelist open on chrome and to select the email address to subscribe to the digest interacting and selecting wasn't working, nor any VO selection modes so I have to enable caret browsing which is essentially the Always Allow Keyboard Commands To Navigate Websites of VO but native to chromium and other browsers and that aside the focus problem work better than the crap of safari where it doesn't know how to be linear or not stuck in infinite loops and other weird behaviors I am not paid well enough to report for Apple each second. (and other problems)
I do dev on my mac and slowly getting use to it but I can't recommend this in good faith to most people.

All issues resolved! 😆

with how people use their mac here (not all but more than some) a chromebook would just perfect for them everything considered except for mathml. For dev you have a full wsl like thing.

I upgraded the OS yesterday and came across the same issues, so thank goodness I'm not going mad!

After the update I was getting incredibly annoyed at focus being stuck in the dock when trying to do file management with Finder.
At least this has helped me in realising that I'm not alone and it's a recognised issue.

I am currently toggling Voiceover on and off to reset focus to the Finder window, which seems to be a work around.
However as soon as you interact or perform certain actions it loses focus and throws you back to the dock again.

Something this easily experienced really should have been picked up and rectified before now, but hopefully gets sorted ASAP in the next update.

Well at least you guys got an update from them, I reported this like in november or decembre and only <10 similar reports and that's it.

I often read comparisons between VoiceOver and NVDA, but the comparison between the clients only is insufficient in my opinion, as it does not reflect how the things really work. For accessibility, there are two parts that have to work well:

• The client: This is the part that makes use of queries via an API to get information of elements (e.g. name, role, state, and value). Moreover, the API provides ways for the clients to perform actions like pressing a button.
• The Accessibility API: This is the most complex part. The client needs a reliable API to get its work done. And for web accessibility, this is even more complex as web content is not rendered like a native UI. To support accessibility here, Apple, for example, uses a so-called WebAccessibilityWrapper in WebKit that populates the needed information via the Accessibility protocol that VoiceOver needs in order to work.

NVDA only makes use of the Accessibility APIs in Windows like MSAA, IAccessible2, and UIA, and sometimes other APIs provided by the controls (they call them Widgets) themselves. So NVDA only have to do the client's work. They don't have to implement and improve a system-wide API.

Apple, on the other side, has to do both sides: They need to ensure VoiceOver as client works like it should, and they need to ensure that the Accessibility API exposes the corect things, post correct events to clients, reacts to specific events as desired, and so on. As WebKit is developed independently and uses its internal rendering mechanism, accessibility experience varies between WebKit (e.g. Safari) and native (e.g. AppKit) applications. As AppKit uses native UI controls, Apple has already implemented how to communicate information, how to react to events, and so on. WebKit, however, has to ensure that they provide the correct accessibility information, e.g. using text markers to make things like read sentence, read word and so on, working. They have to map their internal structure to the Accessibility API.

I don't want to indicate with this post that Apple has no work to do here. They have a lot of work to do, an things get worse instead of better lately. But "A 20MB free software" cannot be compared to a complex system that Apple maintains as a whole, as NVDA is only the client-side of the whole architecture. On the windows side, things seem to be more abstracted. Microsoft and other actors provide the APIs and don't have to bother about how the clients may use them. They can concentrate on API design and architecture. The screen reader manufacturers can focus on the client-side. Apple has to do both sides, and unfortunately, mostly nothing of their work is open source so that the community could help improving the API side. Mostly nothing is documented for browser manufacturers, for example, as they need to implement the Accessibility protocol because they do not use native UI controls but internal renderings. So they don't know how to implement the Accessibility protocol the right way in order to always expose the things that the client (Here: VoiceOver) requests, responding to (undocumented) events, posting proper events and so on. That's why browser experience on Mac is such a mess with VoiceOver. Fortunately, developers can gather information from the WebKit's source code, but in many places, the code is too complex and not documented which ends up in simply "copying" the behavior of WebKit into other browser engines for VoiceOver to work, and therefore sometimes duplicating the bad behavior that exists in WebKit.

Also, missing documentation is the reason why third-party screen readers have been discontinued for macOS. Developers don't know how to post events, react to specific events, how the raw data should be / can be interpreted.

I can also confirm this and I hope that 15.4 fixes a lot of the small annoying things.

Everything you said, in your second to last reply, is exactly why voiceover on macOS is so completely broken. Has been broken since macOS Catalina. Will continue to be broken, until Apple finally gets over themselves and allows third parties to help develop their accessibility API.
The wall garden concept sounds good, great even, on paper ... not so much in reality, however.
As you yourself stated, on the Microsoft side of things, Microsoft only needs to develop systemwide APIs, and allow third parties to develop other APIs to be more inclusive with the system.
If Apple would allow third parties to work on their accessibility API, I think we would see an entirely different voice over experience on macOS.

Just my two cents ...

And I have always said that the api (as a non developer, just intuition based opinion) is the major problem with voiceover. This is exactly why windows 3rd party screen readers are stable because their foundations are, for voiceover on mac nor the client neither the foundation has been stable since I first began my jurney with ventura as my first ever mac.

It's too bad you never got to experience macOS prior to Catalina, let us say between macOS Sierra, and macOS Mojave. Sierra, which debuted (I believe) in 2016, is when Apple decided to rebrand OSX into macOS. It is also when the Mac finally got its version of Siri. Mojave was two versions later, and right before Catalina. I mainly mentioned this, because there were three versions of, "macOS", where SNR, did, not, exist.
Ah, the good ole days ... 👴

Considering everything that has happened since Catalina, I kind of feel like Apple should just go back to Sierra, or even High Sierra, and just rebuild macOS from that particular code. Maybe they would get it right this time around. After all, SnR did not exist. VO plus J worked as intended, And if I am not mistaken, hand-off worked like a dream.
Oh yeah, and the iWork suite was actually a viable alternative to Microsoft Office. 😇