TurnOver - the OG alternative screenreader for mac is now opensource

yea but who would wonna do that.

I don't see how AI can help in this situation, especially considering that it's what got us here in the first place. Writing code is by far what takes the least amount of time, and deterministic tools like macros and Perl can help with the repetitive bits. What takes time is coming up with a proper architecture, and AI sucks at that, so it's optimizing the wrong aspect of development.

In Vosh I put some effort into separating things, but stopped short of deciding how high level the core should go. For example should the core recognize the different kinds of controls and provide them to the add-ons already classified, or should that work be left to the add-ons? Should there be an intermediate level of add-ons that work more closely to the core to do the classification, or should all add-ons work at the same level? In my opinion the core should be responsible for classifying things and abstracting away from the lower levels of Apple's accessibility, like attributes, parameterized attributes, actions, custom rotors, and accessibility graphs. Another question that needs to be answered very early is whether the navigation model should be flat, as is the default on iOS, or should it continue to be a hierarchy, as is the case on macOS? I think that it should be flat, with a browse mode like NVDA's that works everywhere not just in browsers. I'm also against adding too many features too early. I think that we should focus into moving slowly but steadily, and not rush to implement new features until the existing ones are polished.

I don't mind to do the refactoring, but it will be heavily based on what I wrote for Vosh, since I consider it well designed and it's already battle tested as I used the same code to write a context collector for an AI assistant in my last job. Vosh is written in ergonomic Swift, it avoids all the concurrency problems with the accessibility API by relegating all calls to that API to a global actor backed by a dedicated thread, it is organized such that it doesn't need input monitoring permissions, its output module is ready to replace some utterances with audio icons, but it isn't customizable yet. My work can focus mostly on providing a library that can be used both for screen-readers and AI agents, and then people can implement the high level screen-reader on top.

I'm also considering abandoning GitHub and adopting a custom distributed solution that is more in tune with the distributed nature of git. This solution, which I've been working on recently, will be entirely based on public git repositories in the cloud and E-mail exchanges to discuss issues. Pull requests will preferably be based on sending an E-mail with a summary of the commits, the branch, and the location to pull from, as output by the `git request-pull` command. People wanting to use GitHub can continue to do so since it already provides public git repositories. This solution isn't ready yet since I'm waiting for my cloud provider to implement a feature so initial work will remain on GitHub, but I think that the project should have a self-hosted home that's more cognitively accessible to the common user than GitHub.

If people agree with this then I'll make a shallow fork of Vosh and work towards making it a library, with a screen-reader demo notarized by Apple and published once I think it's ready for early testing.

I use Markdown a lot to format my text, and in that particular comment I used it to express all the commands in code voice, which essentially translates to monospaced characters to the sighted. While I understand that most people here are totally blind like me, I'm used to writing to a sighted audience so I cannot stop myself from formatting things with them in mind.

I completely agree with you on managing scope and avoiding feature creep—moving at a steady pace to build a rock-solid foundation is definitely the right path.

To share how I’ve structured this architectural split in Armoni—which I’m planning to make publicly available on Git very soon—here is how the responsibilities and extended capabilities are organized:

Core (Host & OS Integration): Handles low-level AX ingestion, macOS shell interfaces (Desktop, Dock, Menu Bar), system notifications (volume/brightness OSD), and the screen reader’s own UI/settings.

Shared (The Common Engine & Domain Layer):

Multi-Provider Ingestion & Unified Interpretation: We ingest accessibility data from multiple providers (AX API, AppleScript, PDFKit, Chromium CDP, WebKit, Office APIs). Rather than passing raw, fragmented data around, a single Object Resolver/Interpreter unifies and normalizes all incoming data into a single, cohesive semantic representation.

Data-Driven Component Catalogs: Both Native and Web components are defined declaratively via catalogs. This handles roles, states, and navigation semantics cleanly, ensuring outputs (like Speech or Braille cell mappings) stay decoupled from raw AX quirks.

Data-Driven Keymaps & Localization: Key bindings and key labels are fully data-driven, allowing dynamic remapping and localization tailored to different keyboard layouts and languages.

Cursors & Contracts: Manages virtual/flat navigation states, reading snapshots, and strict data protocols.

Utilities & AI Integration (Armoni Intelligence):

Incorporates specialized tools alongside Armoni Intelligence, powered by a locally running AFM3 advanced model.

Provides on-device video audio description, real-time meeting presentation descriptions, advanced OCR, and vision-based contextual analysis.

When native or web applications fail to expose AX attributes, vision analysis programmatically infers and constructs missing accessible names, roles, and states directly into the navigation tree.

App Modules (Extensibility Infrastructure): To ensure app-specific fixes and commands never pollute the Core, every application support package (e.g., modules/whatsapp/) lives independently with its own manifest, documentation, localization files, and src directory. Extensions interface with Armoni via dedicated SDKs in three tiers:

JSON Profiles: Declarative overrides, labels, regions, and keyboard remappings.

JavaScript (via JavaScriptCore): Dynamic scripts for custom app navigation and commands.

Native Swift (.framework): Signed, compiled modules for complex edge cases requiring C-ABI performance.

Both core and module-level localization support are deeply baked into this design. I find that this separation gives us the best of both worlds: a clean, high-performance core alongside a sandboxed, data-driven extensibility model that scales gracefully.

I look forward to opening up the Armoni repository soon so we can explore these architectural ideas and potential synergies on open ground!

hmmmm i didn't think of that when i said i didn't like github. but i wouldn't be apposed to that change as a normy myself. no i am not the dev i was just aggreeing with you but my point from my last comment still stands.

The comment above was really for those devs in the thread discussing major code refactors. I wrote a guide earlier in the thread on submitting bug reports as an every-day user, does this help?

https://www.applevis.com/comment/219815#comment-219815

I'll look into how such a feature might be implemented into turnover itself.

download here.
https://doll-eye.github.io/turnover-updates/
Download the zip at the top. It should be about 36 MB. If you don't want to use it, and if you use Discord, once you have, TurnOver downloaded, you can join the server by going to help menu and going to the Discord link. Alternatively, you can find it on the first page here. Apologies if this isn't helpful for you.

There's a pretty low chance Apple can block this. It's been notarized, not that that doesn't mean anything, but it's not on the App Store either. Not saying it won't happen, but I'm pretty sure it won't. I'm pretty sure TurnOver also has support for braille devices, not sure how extensively though.