Hello applevis,
TLDR, in sequoia in the reorganized commands panel you have this option called Left and right arrow keys: pop up button, where you can cycle between do nothing, akqn, skqn and toggles both. I discovered that whatever option you select there, when you edit the command sets and in general you have
Toggle Arrow-Key and Single-Key Quick Nav On or Off, Toggle Arrow-Key Quick Nav On or Off and Toggle Single-Key Quick Nav On or Off, they are completely independent from the setting mentioned above. So if for example we don't touch it and the default is for left and right arrow keys to toggle the full quick nav, the corresponding option in this browser is not affected, which means that
1 The engineers working there are so bad that they do this simple, tiny logic/design error
2 There is no testing at all or quality control
3 This explains why the implementation in sonoma was so catastrophic as they just jeep adding crappy code on top of an already messy codebase...
Is this the level of care you provide to accessibility, apple?
I understand that brand loyalty for blind is even more precious and recognize that on ios they have set an insane level of touch accessibility standard, but we as a community should know better than defending every bad action of them saying oh voiceover is complicated to code. Yes, screen readers are inherently complex software. But how on earth can nvaccess with less than 5-7 full time employee and around a million dollar budget produce higher quality, more stable software, while apple has virtually infinite resources and the talent with probably way higher pay checks?
Like this is just so basic stuff! Don't hard code (writing tools in action menu), just craft the thing more carefully, please.
By TheBlindGuy07, 17 February, 2025
Forum
macOS and Mac Apps
Comments
Plus the hole concept of…
Plus the hole concept of quick nav seems to be another overhyped thing that doesn't work in practice. Like... Okay I have full quick nav on. I'd expect that the find commands with single key like h, f, etc.. wouldn't sync with the actual rotor so I can quickly jump to heading level 3 with 3 and then the with the rotor set to words do down arrow to read, and so on, without both constantly syncing. This is the regular behaviour when I do vo cmd h for example, I can then do vo cmd down, but for whatever reason this doesn't work where it should be the most essential. And I haven't seen it mentioned anywhere yet. Yes, I can interact, but when you are in chrome or safari and you have a heading level 3 with an image and a link, you have to interact at least twice if not more and hope to be able to read it by word or characters with shift arrows or just the arrows. In tables on mac again vo is less smarter than on ios as the rotor doesn't switch itself to navigation so we can just do down arrow when in quick nav. I mean on ios the rotor doesn't go itself to rows but at least in some context there is an option to let the rotor change depending on the context for example which isn't the case on mac.
I have already reported all this to apple.