TurnOver - The Mac screenreader for when voiceover isn't quite up to it... Call for closed beta

Regardless of whether the code is supervised or not, reviewing code is significantly harder than writing it. If you lack the required competence to write it, you are definitely not a competent reviewer. That's another problem with vibe coding; people thinking that reading code gives them anything even remotely close to the perspective of people who write actual code. Humans aren't good reviewers, and existing AI isn't good at coding.

I'll wait until this becomes open-source to cast further judgment, because I'm yet to read good complex code generated by any kind of AI, but if I find the code to be genuinely good, I will be the first to admit it. I've been asking for demonstrations of good code written by AI for years now, and so far have been served none, with most people conveniently claiming trade secret as an excuse to not fulfill my requests.

I definitely don't want to go another few rounds on here over vibe coding. But what I would say is that I don't think we will ever get an alternative to VoiceOver without it. I think it's too big to be done as a hobby and there isn't going to be a good enough business case for it to be commercial. You probably understand as much as anyone what the scale of the task is.

o boy.
it seams as if every post like this goes into an ai vs no ai thing as soon as this is said, and it never goes back to what the post was talking about at the start.
like i understand people hav there reasons for doing this, but if rools permet, would it be better to make another post on this matter?

I've seen some truly horrible code written by human programmers. Heck I've written some horrible code myself, when I've needed a quick tool that just works or wanted to prove a concept before committing a lot of development time. So it's not just AI. And AI code is improving with every model. But this comes with caveats, one being that you have to prompt well. For example, unless you specify the version of the programming language you want to comply with, most LLMs will write code for an older standard, such as Swift 5 instead of Swift 6 for example. And when you're writing for platforms like Apple's, where you're reliying heavily on their own APIs and frameworks, unless you tell the AI to adhere strictly to the guidelines and documentation for those APIs and frameworks, it will often go off and write messy code to implement things that are already covered, or to solve problems that never existed.

And then there's the plan and iterate loop, which is important. Have the AI work with you to plan. Have it interview you, have it research (including the aforementioned documentation), and have it formulate a plan that you can then work through. Get the plan watertight before you build anything, and there's less chance the LLM will go off on a tangent and leave you with a messy codebase. And know that some models are better at some programming languages and frameworks than others. I personally think Astra is better than any claude model at Swift, and it has a far better understanding of Apple's platform APIs and frameworks. claude is slightly better at front-end web design in React, and they're all pretty equal when it comes to older languages like C and Python, though I find the Open AI models reason better and produce less slop than any Claude model I've ever used, which have mostly been a tremendous waste of time, effort and money.

There are agent skills that cover a lot of this and if you use AI tools in a development workflow, where you're working along-side an AI, not purely vibecoding, you'll develop prompts that keep the model in line. We're long past the days when all models wrote sloppy code regardless of how you prompted them, but we're not at the point where simply testing an app, as a user does, is sufficient to prove the quality and security of a vibecoded app, yet. AI-based hostile codebase audits are useful, and can also be used to help refine a model's output for your specific usecase through custom skills or good agent instructions, but often these are done with the same models that wrote the code in the first place, so it's not really a second opinion.

Bringing this back to turnover. I've put forward my arguments to Oliver regarding this being, if not open source, then at least the sum of contributions from a small team with some dev experience. I personally have no problem with an AI being used to work along-side developers to speed up the development of a final product. We demand a lot from our screenreaders these days, and if you think back to when NVDA started, its development took years from those early 0.x releases to reach a point where it was truly a viable commercial alternative. Would you rather a voiceover alternative by Christmas, or in a few years?

But I also understand the risks and implications. I don't want to see a closed-source screenreader, because it's the reason we're in the position we are now. If Apple had simply opened up Voiceover, even to a small team of committed
blind devs, we wouldn't even be having this conversation.

I also understand Oliver's position in wanting to be compensated fairly for his time and for his compute to be covered. That's reasonable, of course, but it presents a dilemma. You either charge for the product, or you have to find some other income source, be it support, training, charging for add-ons and plugins for a free core, or commercial licensing deals.

Charging money also introduces the berden of providing technical support for the product, and meeting moral obligations (if not financial ones) to users who may be less tech literate. This is especially true for a product aimed at a small community. That costs time, which when you're a one-person team is time you aren't spending on the product. Open source projects don't have those obligations. There's nothing stopping you offering support as an open-source dev, but there's less expectation to do so.

And finally, there's fragmentation. Were Turnover to remain a closed-source, wholely AI-developped project, it is probably not something I would consider using myself, based on my own personal choice. I would probably develop an open source solution from scratch. Or I would stick with Voiceover, since I'm comfortable working around most of its annoyances, besides a few that really do bother me. If I did release my own product, it's not a competition. Use what you like, and what works for you. Multiple screenreaders have co-existed peacefully on the windows side for decades and while I think it's better to pool resources for the benefit of everyone, as aptly demonstrated by NVDA, sometimes people want different things, or have different ways of working, and that's perfectly OK.

i use codex to make my website, it's honestly dun a very good job.
i haven't tried making an app for android, windows or mack using it though but i'd say it would do a pretty good job.
back to ternover.
the reason i hav issues with it i guess is because I think it uses nvda or another keyboard layout for some of the keys, not all of them but some imo and it's confusing when i command i would noramly put into voiceover that works doesn't on t o

I've seen some truly horrible code written by human programmers.

Two wrongs don't make a right. Humans writing bad code doesn't excuse using AI to do the same. Technology is supposed to simplify our lives, and AI can be used for that as a reviewer, which it has already proven to be far superior to humans; as a coder, however, it holds no candle to skilled human coders, so people should stop using it to generate production code. I don't care if people use AI to write quick scripts, as I've done it myself, but I draw the line when it comes to production code. For example very recently I exported all the E-mails sent to my old domain to an mbox file, and then asked Gemini to write a Python script to extract all the unique domains that I received mail from in order to update my contact information on all those services. That script is not production code, it's not going anywhere outside of my computer. if it fails I'm the only one who suffers, and it's so small that reviewing it was trivial, but none of this is the case for production code.

As for the project itself, I wasn't planning on using it because VoiceOver works well enough for me. However learning that it's vibe coded only makes me even less willing to check it out. I said in my previous post that I'd review the code if it's ever made open-source, but I won't go any further than a superficial skim, which is usually all it takes for me to find problems in AI generated code.

Audio ducking, as in NVDA: other apps' sound is lowered while TurnOver speaks. It's off to start with, under Settings, Speech, or Caps Lock Shift D in the Windows style. The first time, macOS asks to let TurnOver record system audio; that's how it lowers the sound, and nothing is recorded or kept.

I suspect that VoiceOver actually lowers the volume of everything else playing on its output device through CoreAudio, which doesn't require audio capture privileges. I don't recommend starting a recording session even if you discard the data because if you record from a microphone, that will mess with bluetooth headphones like the AirPods, making everything sound worse and possibly in mono as well, plus it drains a lot of battery.

From build 18, ducking uses macOS’s own ducking, the same mechanism the system uses for its voices and there’s no permission to grant, no sound passes through TurnOve at all now.

What's the mechanism? Is it in CoreAudio? Because I never found anything specifically related to audio ducking in CoreAudio and just thought that it was just a matter of lowering the volume of everything else playing on the same device. I'll investigate this in the mean time until you find the time to reply, since I'm genuinely curious.

Just found the functionality in AVFAudio. The web documentation is not very accessible (I personally read it in Xcode), but essentially it's just a property of AVAudiosession.

I think you should be fine. I did have to reinstall macOS, though, but that had nothing to do with TurnOver, in fact it was from a whole completely different reason because of me screwing around with the speech libraries. I've used this a couple of times and it works very well.

While I appreciate your work on this Oliver, for me I don't like the direction. While it's great to have plugins, I'm still too uncertain about the core. Just because something works, doesn't mean it is optimal or even safe. I also think fragmentation and inconsistency in the screenreader space is the very last thing we need, so having 2 versions, especially 1 that frequently drops back into Voiceover, is not a direction I can get onboard with. For newer, or less experienced MacOS users, that is only ever going to cause confusion. And for me, as a highly proficient voiceover user, it is something that would become so incredibly annoying I would just stick to Voiceover.

I really would love to be fully onboard with this but if you're set on this direction, I'm out, I'm afraid.

Yeah, I'm honestly starting to see some slight issues with it myself now too. Earlier it was pretty easy to navigate with the arrow keys. Now I have absolutely no idea what the hell I'm doing half the time.

But hell, if it allows me to finally use steam, I can work with that. But honestly, unless it's somehow it's better than VoiceOver and most other aspects or starts to become a genuine rival to VoiceOver. I probably won't use it outside of steam, especially the commercial part.

I'm not saying I'm against plugins. Far from it. I like plugins, add-ons are one of the many thigns that make NVDA so great. A simple plugin format is exactly the kind of thing that allows non coders especially ot use AI to successfully bring compatibility and functionality to otherwise inaccessible applications, and it's why there are a ton of successful NVDA addons that are purely vibecoded and work very well.

I'm saying that I'm uncomfortable with a closed-source, solo-developped, core written entirely by AI. That is ultimately what would make me walk away. I still think the money is in the commercial application and sale of support and training for an open source product. It probably doesn't help that I'm no fan of claude and the way it writes code, but that is by the by.

I actually really like the flexibility between voiceover commands, NVDA commands or both. There are things I really like about Voiceover's way of navigation and screen presentation, but there are things I also really mis from my Windows days using NVDA, or, prior to that, Jaws. I think a screenreader that brings either of those solutions, or a combination of both, to the Mac is a great thing. I would never be one to encourage you against producing something feature-rich. The more functionality the better. Especially since you've already spent time and compute building it, why strip it now?

Simply ship with a minimal settings configuration, and the user can enable features or configure the app as they please. You might even create a first-time onboarding wizard for this configuration. When I started writing Simulcast, it was the most basic podcast client. It now has over 3 million possible combinations of settings. Versatility is not a bad thing, and neither is being rich in features. Neither is wanting a MacOS screenreader to operate like a Windows one, or vice versa. If you'd asked me in 2014, when I started moving full-time to Mac, I'd have loved a screenreader that was more familiar to help ease that transition. Now, with more than a decade of living exclusively with Voiceover under my belt and having figured out most of its bugs and workarounds, I find it difficult to go back to using a Windows machine. Even then, I've enjoyed Turnover's amalgamation of the two.

The thing you can fix, with regards the transition between turnover and Voiceover, is the speed that it happens. There is that period where turnover quits and voiceover starts back up again that will always be annoying when switching between supported vs unsupported apps, and there's really nothing you can do about that. That is probably the main reason why a screenreader that was intended otherwise work along-side Voiceover would never really work. And in truth, turnover is already great with unsupported apps. So once you better support a few more UI elements, like tree view tables and such, you probably don't really need that compatibility layer.

I said worked :) not is working. you're 100% right of course.

Jaws worked because they were in the commercial field. It helped that they were the first, but they were usually the de facto solution supplied by access technology specialists and training firms, or at least certainly here in teh UK, unless you requested an alternative like Window Eyes or even Hal for reasons of cost. I was lucky enough to receive my first computer through grant funding from a UK organisation that no-longer exists, which at the time provided a Windows PC setup and a copy of JAWS 4.51 that could also be installed on a couple of machines at the mainstream primary school I attended.

I don't know how the windows side works now as I've been out of the market for over a decade, and am not really active in the VI community. I do remember the early versions of NVDA (the 0.x versions) when it was good, but basic. It sat somewhere between JAWS and Narrator at that time. Then the community got ahold of it and it started to be developped at pace, and quickly became not only a viable alternative but a genuinely better one.

A quick scroll through the NVAccess website shows how at least some of their money is made. There are several training books, a couple of synths, and the offer of online or telephone support. There's also a donate button. Given the number of VI folk who have kindly reached out and offered to put money into my own projects, I'd bet a lot more could be raised through a donation model than a subscription one.

nobody, certainly not me anyway, is saying that you shouldn't be compensated for your time and effort, and earn a fair wage. If it came across that way, I apologise. I don't doubt for a second that you've invested a lot of time and significant money into this, I am fully aware of the cost of compute.

For me, it is entirely caution, and no reflection on the cost of the product. I'd just feel more comfortable running the solution beyond testing if there were experienced devs at least checking over the code, especially given the level of system access involved. Beta testing a user-facing application doesn't tell you anything about its security risk or potential affect on hardware, for example SSD storage wear. Ultimately it's your project, and it would be a shame to see it fall by the wayside.

I completely aggree with this comment here.

I think that one problem that you are failing to account for is that this is a project that requires high maintenance, which you won't be able to do all by yourself as the number of supported applications grows thus making it a bad choice to sell as a product. If I decided to work on Vosh again, which I won't, I'd do just an open-source core with some example add-ons, in AppleScript or Python, and let the community take over and do the rest. In Vosh my goal, which I failed to accomplish, was to find a general solution to most or all the problems, precisely because I didn't want the burden of having to support lots of individual applications and wasn't expecting much interest from the community, even though getting the community involved was also a goal.

I hate to sound like a broken record here, but again I completely agree. As I've said before here, I'm kindly developing a rugby league website. I've developed it for seven weeks straight and I am starting to get burned out. So imagine what it's like when you have a community of people who are desperate for anything better than VoiceOver on you when you say that you've made something that might be better than VoiceOver in certain aspects. I don't have a community behind me and even I'm half stressed half the time.. Not to mention, this is an app you're making nowhere near a website, Jesus if I was doing what you were doing I'd probably have like a panic attack or more per day