TurnOver - the OG alternative screenreader for mac is now opensource

By Oliver Kennett, 20 October, 2026

Forum

macOS and Mac Apps

Hello everyone!

So, after much soul searching, thinking about what I want for the future and whether I could make this a sustainable concern, I've decided TurnOver is now free and open source, under the GPL. Anyone can use it, read the code, check it, change it and build it themselves.

I started out with this on a whim. Safari and Word were unusable for me, so I set about fixing them for myself, and discovering it was possible to fix not only those two apps but improve the logic and layout of others, I realised there might be something here. It was exciting. It was wild! I was doing something many of us had hoped for for so long. Of course, it's a big undertaking. As pointed out by several commenters, maintaining the code base, keeping up with apps as they change and generally keeping the whole thing ticking along takes a significant amount of time, as it has. So, to make it sustainable, I thought, rightly or wrongly, I'd keep it closed and charge a small subscription to cover my time.

From speaking to others, I came to understand that most people won't pay for a screen reader when a free one is built in, so I wouldn't get enough to make it worthwhile. Also, I admit, other ventures on here did make me realise that even a half-baked free screen reader that's open source might be preferable to a fully functional, notarised one with a plan for sustained development. *mutter mutter mutter*

As it stands, I'm happy. I've got a screen reader that rocks. All I really wanted. I just thought others might want it more.

What this all means:

- TurnOver is free for everyone. No tester keys, no waiting list, no price.
- The code is on GitHub: https://github.com/TurnOver-For-Mac/turnover. Yes, it was written with an AI, and tested by hand, with a hundred-odd unit tests. It's all there to judge, and I'm hoping there's something useful in it for people to build out from.
- It's a spare-time project. I'll keep working on it a few hours a week, on what I can. No support or roadmap promises. I'm going to do what I should have done before: get on with finishing my book. It's amazing what procrastination can look like! This is still a project I care deeply about. There are areas of the Mac I still want to reach and fix. I'm a tinkerer and a maker, coding and 3D printing are my jam. It's just not going to be viable as a larger commitment.
- Bug reports and ideas go through GitHub's issue form now, not email.
- Fixes, plugins, guides and testing are all very welcome. Plugins are the easiest way in, no Swift needed.
- The released builds are still signed and notarised by me, and update themselves. Nobody else can ship an update to your copy.

If it's useful to you and you'd like to help with running costs, there's Ko-fi, no account needed: https://ko-fi.com/oliverkennett. It's in TurnOver's menu too, under Support TurnOver. GitHub Sponsors is coming.

Download and guides, as before: https://doll-eye.github.io/turnover-updates/

A massive thank you to the testers, who sent hundreds of careful reports and made TurnOver what it is. You are heroes, rocket men and women willing to climb onboard a wild ride. You rock.

Stay frosty

Options

Comments

Pro tip for using GitHub

An option to avoid GitHub's web interface is to install its command-line tool called gh. I do so using MacPorts, but HomeBrew should have it too.

To install gh using MacPorts, type:

sudo port install gh

And then enter your password when prompted.

Next, generate an ssh key for authentication to GitHub if you don't have one already by typing:

ssh-keygen -t ed25519

And answer all the questions, making sure to remember both the name of the private key file and the passphrase.

Next, append the following to your ~/.ssh/config to make ssh authenticate using the new key:

Host *
    UseKeychain yes
    AddKeysToAgent yes
    IdentityFile ~/.ssh/id_ed25519

Replacing id_ed25519 with the file-name containing your private key.

Next, add the authentication key to the ssh-agent for automatic remote authentication as follows:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Replacing id_ed25519 with the file-name with your private key, and entering the passphrase.

Next, authenticate gh to GitHub by typing:

gh auth login

And following the on-screen instructions.

The following is optional, and will make the mate utility from TextMate the default editor and pager, which are used by both git and gh, so install TextMate if you haven't already and install the mate utility from its preferences.

First, create a bin directory in your home directory by typing:

mkdir ~/bin

Next, create a file in ~/bin/lesser with the following content that removes all terminal control sequences from the output and pipes it to TextMate:

#!/bin/sh
perl -pe 's/\e\[[\x30-\x3f]*[\x20-\x2f]*[\x40-\x7e]//g' | col -xb | mate

Next, give executable permissions to the file that you've just created as follows:

chmod 755 ~/bin/lesser

Next, edit your ~/.zprofile and append the following two lines:

export EDITOR='/usr/local/bin/mate -w'
export PAGER=$HOME/bin/lesser

All done. Now you can interact with GitHub almost entirely from the command-line and get the output sent to TextMate.

The following command clones Turnover to a subdirectory in the current directory:

gh repo clone TurnOver-For-Mac/turnover

The following command lists all the issues in Turnover using TextMate as the pager, if you configured it as instructed earlier:

gh issue list

Or you can avoid TextMate and print directly to the console as follows:

gh issue list | cat

For example the following are the issues currently open for Turnover at the time of this comment:

jps@alpha turnover % gh issue list | cat
25  OPEN    Braille: NVDA's braille features (panning moves the cursor, focus context, review cursor, read by paragraph, settings)  idea    2026-10-21T16:14:56Z
14  OPEN    Issue with browsing for files   problem 2026-10-21T13:05:58Z
12  OPEN    Speech rate jumps when CoExist is turned on or off (Eloquence)  problem 2026-10-21T11:07:41Z
11  OPEN    Braille: the TurnOver menu is not shown on the display; it keeps showing the app behind problem 2026-10-21T11:07:39Z
10  OPEN    Braille: with CoExist off the display shows only VoiceOver off and nothing else (Focus 5)   problem2026-10-21T11:07:38Z
4   OPEN    Browse mode: timing of keys in the virtual buffer   problem 2026-10-20T15:25:06Z
3   OPEN    Reader state is hard to isolate in tests    idea    2026-10-20T15:25:05Z
2   OPEN    App-specific exceptions living in shared code   idea    2026-10-20T15:25:03Z
1   OPEN    Keys pile up while a slow page's buffer is built, then run all at once  problem 2026-10-20T15:23:28Z

Issue #1, for example, contains the following:

jps@alpha turnover % gh issue view 1 | cat
title:  Keys pile up while a slow page's buffer is built, then run all at once
state:  OPEN
author: Doll-Eye (Doll Eye)
labels: problem
comments:   0
assignees:  
projects:   
milestone:  
issue-type: 
parent: 
sub-issues: 
sub-issues-completed:   
blocked-by: 
blocking:   
number: 1
--
Seen in Safari on 20 Oct 2026 when Safari stopped answering accessibility questions: each rebuild of the page's reading buffer took about two seconds on the main thread, every key pressed meanwhile queued ("kb:tab answered after 2012 ms: its script runs now", five in a row), and they all ran together when the build finished.

Two parts:
1. Build the buffer without holding the main thread for seconds (a time budget, finishing in the background, or keeping the old buffer while a slow app is rested by AXHealth).
2. Repeats of the same navigation key that waited more than about a second should not all run: run the last one, say that the page was slow.

The log lines above come from InputManager and ScriptHandler.askMain; the buffer is built in WebBuffer/BrowseMode.

All gh commands have dedicated manual pages, so for example if you type:

man gh-issue-view

That will display the manual page for the view subcommand of the issue command, and the same works for git commands too.

Since the man command uses the configured pager, you will also get the manual pages displayed in TextMate, if you configured it earlier.

Re: Buffering

Buffering has two problems:

You are no longer sourcing information from a single source of truth;
It exchanges almost imperceptible delays in responses by a huge delay at the start for complex applications as all the content is queried for buffering.

Plus it's solving a non-existent problem which is the assumption that just querying the application as the single source of truth when needed is slow. VoiceOver does that and in my experience it's not slow unless applications themselves are slow to respond to queries. Therefore to me buffering only adds unnecessary complexity to the code.

Re: Pro tip for using GitHub

lovely thanks for this

Very keen for people with experience to join in

Regarding the buffer, it is the NVDA virtual buffer idea and only applies to webpages to keep the behaviour of the screenreader predictable.

I'll be the first to say, I'm not experienced at this. All I've done is vibe coded a screenreader to my specifications that by and large achieves what I want, to be better than voiceover. It's not complete by any means, it's more of a beginning, a proof of concept, an idea and, yes, a challenge.

I do agree that skils are needed for this beyond pushing money into a slot and asking for wishes which is why I want people to join in. It is also far further than anyone else has got in creating something that is a viable alternative to VoiceOver. It works. I'd like people onboard who push back, who critique, who have views counter to my own. I'm learning as I go but, I don't think that is enough. Please hop on board if you have value to add.

My ultimate (longterm) hope for this project

Personally, one of the things that has prevented me from fully embracing TurnOver, even in apps where it's currently supported, is the fact that it runs alongside, rather than in place of, VoiceOver. Even if the two screen readers function similarly, it's still two separate screen readers running side by side, increasing the potential for bugs, conflicts, and user friction.

NVDA, on the other hand, is a full-featured screen reader, meaning that I can acclimate to one set of commands and concepts when using Windows, and apply them across the operating system. I don't need to think about what screen reader will work in one app versus another, unless I, for example, purposefully quit NVDA and turn on Narrator.

I think if TurnOver could eventually function as a full-featured screen reader, I could see myself using it full time. I know development is only beginning, but I think the ultimate, long-term goal of making it as full-featured as possible across apps could really move the Mac accessibility landscape forward in ways not thought possible a short time ago.

Completely agree with Tyler

completely aggree, this is the type of things i'd want apple to use.

Buggy?

Is it me, or is this ? buggy as hell? It gets stuck all the time for me, loses focus in apps, fails to interact, fails to announce windows in alt tab and so on.

Re: Buffering

The intent is to provide a virtural cursor, similar to NVDA or JAWS (or pretty much any windows screenreader) whereby the page is read like a document. They all achieve it by reading the content into a buffer and them browse / focus mode moves you in and out of that buffer for reading. However, if it's possible to reliably facilitate the same navigation without building a buffer first, then it would be something worth exploring as it would mean faster load times and better support for dynamic content..

Couple of things

If you have bugs, please report them.

Turnover can be used exclusively, I've just set it up so there is a backup if an app isn't working as well as you like. Go into settings down to expirimental and turn off coexist. You can then turn off voiceover. You do need to make sure the option is set to turnover everywhere which is toggle by doing the turnover layer command control comma and then a.

the reasoning was to let people switch easily back and forth rather than simply giving up on turnover.

I feel I'm repeating myself. It's a beta. It has bugs. don't expect perfection. We'll get there, hopefully, but we're doing this in our free time. tell us what is going wrong, file a bug report and we can iron the issues out.

thanks