New Accessible TeamTalk Client for Mac – Looking for Beta Testers

By Mathieu, 18 March, 2026

Forum
macOS and Mac Apps

Hello everyone,

I've developed a native TeamTalk client for macOS that's fully accessible with VoiceOver. As you know, the official TeamTalk version on Mac is completely inaccessible, so I built an alternative from scratch.

What's included:

  • Full keyboard navigation β€” Cmd+1/2/3/4 for UI areas, F5 for nickname, F6 for status, etc.
  • VoiceOver announcements for all events (users joining/leaving, private messages, file transfers)
  • Native macOS interface (no ugly web wrapper)
  • Saved server management with quick access
  • Browse and join channels with optional password protection
  • Private messaging with full conversation history
  • File sharing with visual progress indicators
  • User administration (for server admins)
  • Advanced microphone settings:
    • Enable/disable audio processing
    • Noise suppression (Noise Gate) or Expander with fine-tuned controls over threshold, attack, hold, and release
    • Peak limiter with auto or manual mode
    • Multiple presets for different use cases
    • Professional-grade tools to eliminate feedback and control voice peaks

Current state:

The app is functional and ready to use. The interface is clean, accessible and looks good β€” because using VoiceOver doesn't mean the UI has to be ugly.

Important:

The app is unsigned (no budget for Apple Developer Program yet). You'll need to authorize it in macOS security settings.

Interested?

If anyone wants to test, I can set up a beta distribution system. Your feedback on features, keyboard shortcuts, or missing functionality is welcome!

Options

Comments

By AppleVis on Friday, April 3, 2026 - 21:50

Member of the AppleVis Editorial Team

Hi all,

Friendly reminder that while we do now allow the usage of mild profanity on AppleVis when used for emphasis or expression, strong, sexualized, or graphic profanity--including words like the F-bomb--is prohibited under all circumstances regardless of context. Any posts containing strong profanity may be subject to removal at moderators' discretion.

Thanks,

The AppleVis Editorial Team

By Jonathan Candler on Friday, April 3, 2026 - 22:23

Then you need to tell us what's aloud and what is not, because yall lifted profanity restrictions but you never told us what we can and cannot use and in the case of context, what contexts. Not my issue if I didn't know. Note I'm not the only one who expressed this neither, a few members did in said mod thread. Sighs the double standard astounds me! Great you lifted and relaxed the profanity restriction and my mind went, kay as long as I'm not harming anyone we good. You should have told us in the beginning what was aloud and is not from the very beginning and sorry if I do not look at the rules as much. Didn't know I needed to. Maybe if a list was provided I would have known but sorry if I didn't.

By AppleVis on Friday, April 3, 2026 - 22:57

Member of the AppleVis Editorial Team

Hi Jonathan,

The below is taken from the original post announcing the loosening of profanity restrictions:

  • While discouraged, limited use of mild profanityβ€”defined as non-sexual, non-graphic language generally considered acceptable for a broad audienceβ€”may be permitted when used sparingly for emphasis or expression. Such language must not be used to harass, intimidate, demean, or degrade any individual or group. Profanity that is strong, sexualized, hate-based, or graphic is strictly prohibited, regardless of intent or context. Determinations regarding what constitutes β€œmild” versus β€œstrong” profanity are made at the sole discretion of the AppleVis Editorial Team and will be evaluated on a case-by-case basis in accordance with this policy.

While we appreciate that some may disagree, we believe the F-bomb falls into the "strong profanity" category. We have addressed other instances of usage of that word as they have arisen, including in the original thread announcing the changes. It is our strong preference to avoid content removal unless it is absolutely necessary, thus the community reminder.

By Dan Eickmeier on Saturday, April 4, 2026 - 02:14

I agree about the iOS app, Jonathan, and its lack of file sharing and managing user accounts on a server. Those things should be able to be done on iOS as well, but who knows if the developers there, will do anything about that. It's awesome that Mathieu here, is working on this alternative to the QT client on the Mac side, as things that worked ok, previous to version 5.18, or maybe 5.19, of the QT client, are seriously not since then. This alternative in the TTAccessible app that is in development here, is working absolutely great so far, and is becoming my go to TT client on the mac. It is what a Mac TT client should be. Nice, accessible, and putting VO users first. Back when you could arrow through lists in the QT client, I found there was a bit of a lag, between the time when you'd arrow, and things would be spoken, and if you went to quickly, things would be missed. Unlike that, this is very very nice and responsive. Beta 5 and its added features, are working well.

By Johann on Saturday, April 4, 2026 - 02:15

Edit: yeah, this crashing is actually quite bad, it even does it when I get a private message LOL.
So, I'm experiencing more random crashing in this version, like when sending a channel message the app crashes, even when just command tabbing back to its window also crashes it.
Aside from that, good work on this, the auto recording works fine, I have yet to test some of the other stuff.

By John Lipsey on Saturday, April 4, 2026 - 17:07

I'm beyond excited to try this out when I get home from work tonight. It's probably loads better than my current solution to mac TT accessibility, which is to download and run the iOS version on my M1 Mac.
This should be night and day better experience wise.

By Mathieu on Saturday, April 4, 2026 - 17:29

Hi everyone, beta 6 is a quick follow-up to fix crashes reported in beta 5.

Download: ttaccessible-1.0.0-beta.6-1.zip

@Johann β€” Sorry about the crashes! There was a bug causing the app to crash when sending or receiving messages. This is now fixed.

@Dan β€” Thanks for the kind words, really glad the app is becoming your go-to TT client!

What's fixed in beta 6
  • Fixed a crash when sending or receiving messages (affected both channel and private messages)
  • Fixed potential crash with clickable links during window switching (Cmd+Tab)
  • Relative timestamps now show "now" instead of "in 0 sec" for recent messages
  • Relative timestamps auto-refresh every 60 seconds

By Jonathan Candler on Saturday, April 4, 2026 - 18:14

How you gettin' round the TT sdk with out paying a shit load of money.

By Casey Reeves on Saturday, April 4, 2026 - 18:27

The tt sdk is basically in a permanent trial mode. You are not even forced to stop using it after 30 days have passed. You can just continue on using it. The so-called license on the website says that you are required to buy a license after 30 days have passed, and yet the software remains perfectly usable afterwards. Of course since he sells this so-called sdk at a totally insane price, noone will ever buy it.

Bit of a braindead move imho to make your sdk cost a ton because that just prevent ecosystem growt. Very stupid move indeed.

And even things like the tt media bot take this exact approach and don't pay for the sdk.

By Matthew Whitaker on Saturday, April 4, 2026 - 18:46

Using the latest version of the beta. After sending a channel message, I did shift tab to get out of the text field, then the app crashed. Just letting you know.

By Mathieu on Sunday, April 5, 2026 - 15:21

Hi Matthew, thanks for reporting this! I can't reproduce the crash on my end with Shift+Tab after sending a message. Could you provide more details? When the crash happens, macOS should show a crash report dialog with a text field containing detailed information. If you could copy that content and send it to contact@mathieumartin.ovh, that would really help me track down the issue. Thanks!

By John Lipsey on Sunday, April 5, 2026 - 21:28

I connected to a teamtalk where my account is set to autojoin a channel. My regular mac teamtalk client and iPhone teamtalk client respect this autojoining, but TTAccessible doesn't.
The autojoining is set at the account level on the server, not in my TT configurations.
I'm not sure why this is happening, but if you can look into it I would be most appreciative.

By Mathieu on Sunday, April 5, 2026 - 23:21

Hi John, thanks for reporting this!

You're right β€” the app wasn't actually joining the server-side autojoin channel. It was just detecting that one was set and returning early without doing anything.

This is now fixed in beta 7, which I'll post shortly. The app will now properly resolve the channel path and join it automatically on login.

By Mathieu on Monday, April 6, 2026 - 00:55

Hi everyone, beta 7 is here with a nice mix of bug fixes and a new feature.

Download: ttaccessible-1.0.0-beta.7-1.zip

@John Lipsey β€” Your autojoin issue is now fixed! The app will properly join the server-side autojoin channel on login.

@Matthew Whitaker β€” I also added proper Tab/Shift+Tab navigation between all UI areas, which should fix the crash you reported. Let me know if you still experience it.

What's new in beta 7

  • Copy Server Link (Cmd+Shift+L): Generate a tt:// link for the current server and channel. An editor lets you review the info before copying, so you can remove your credentials if you want to share the link publicly.
  • Open tt:// links: Clicking a tt:// link now opens TTAccessible and connects to the server automatically.

What's fixed in beta 7

  • Fixed server-side autojoin channel not being respected (the app detected the setting but never actually joined)
  • Fixed potential crash when pressing Shift+Tab after sending a channel message (missing keyboard navigation chain)
  • Fixed several force unwraps that could cause crashes in edge cases
  • Improved French localization: removed anglicisms, fixed awkward phrasing in several labels

By Johann on Monday, April 6, 2026 - 05:01

Can you perhaps make the keyboard shortcuts to subscribe/unscribe to events just control+numbers instead of command+control+numbers? Would be easier to press if that's the case.
Also, VO doesn't indicate that the subscription events are checked when they are, like voice for example.
And another thing, can you make the server/channel tree behave like in the qt client, where if you're not in a channel it's collapsed and auto expand when you join that channel, would also be helpful if VO says it if the channel is collapsed/expanded.
Thanks for all the work you're putting into this.

By Mathieu on Monday, April 6, 2026 - 09:39

Hi Johann, thanks for the suggestions!

Keyboard shortcuts

Good call β€” the subscription shortcuts are now just Control+number (and Control+Shift+number for intercepts) instead of Command+Control. Much easier to press. This will be in the next beta.

Subscription toggle state with VoiceOver

On my end, VoiceOver does announce "checked" or "unchecked" when toggling subscriptions. Could you give me more details about how you're accessing them? Are you using the menu (User > Subscriptions) or the keyboard shortcut directly? That would help me figure out what's going on.

Channel tree collapse/expand

Also done for the next beta β€” channels you haven't joined are now collapsed, and when you join a channel it auto-expands. VoiceOver announces "collapsed" or "expanded" when you navigate with VO+arrows, and you can expand or collapse channels with the right and left arrow keys. This is standard macOS outline view behavior, same as in Mail or Finder.

Thanks again for the feedback!

By Mathieu on Monday, April 6, 2026 - 15:26

Hi Johann, that's odd β€” on my end VoiceOver does announce the checked/unchecked state in the User > Subscriptions menu (for example I get "βœ“ Private Messages" when it's enabled). I'm on macOS Tahoe 26.4.

Could anyone else on the thread confirm whether they experience this issue? That would help me figure out if it's specific to Johann's setup or a broader problem.

Thanks!

By Dan Eickmeier on Monday, April 6, 2026 - 19:31

Hi, whether subscriptions are checked or not, is spoken just fine with VoiceOVer here. I'm also on the latest version of Mac OS Tahoe.

By Jonathan Candler on Monday, April 6, 2026 - 19:39

Will this be ported to IOS as well? If this thing has account creation and file sharing you'll blow the lazy ass TT devs out of the water and there's no excuse for not having account creation nor file sharing after all this time. I keep giving devs feedback after feedback about all of this as well as what I said above in my other posts here in this thread but they do not listen! Clearly they do not care at all about our suggestions.

By Matthew Whitaker on Tuesday, April 7, 2026 - 00:56

Just reporting a small issue I ran into. The text field for typing the default nickname was behaving oddly. When I tried to use Command + A to select all and delete the existing text, it didn’t work. Instead, anything I typed just started writing over the existing text in an inconsistent way.

I was eventually able to enter my name, but it was a bit tricky and confusing to navigate. Thought I’d pass this along in case it helps identify a bug.

By Johann on Tuesday, April 7, 2026 - 10:14

Uh, sorry for all the confusion LOL, turns out I wasn't focused on a user when trying to test that.
Maybe is it possible to make those menu items dimmed/disabled whenever you're not focused on a user, to avoid confusion?

By Mathieu on Tuesday, April 7, 2026 - 19:41

@Matthew Whitaker β€” Thanks for reporting the nickname field issue! I was able to reproduce it. What was happening: when you select all and delete the text, the field snaps back to the old nickname after a short delay (300ms), so it looks like your new text is writing over the old one. This is now fixed β€” the field will stay empty until you type a new name. The fix will be in the next beta.

@Johann β€” Good idea! I'll make the subscription menu items dimmed/disabled when no user is focused, so it's clearer that you need to select a user first. Coming in the next beta as well.

@Jonathan Candler β€” iOS is something I'd love to do eventually, but right now the focus is on getting the Mac version solid first. One step at a time!

By Nut on Wednesday, April 8, 2026 - 07:36

With Discord and possibly many other mainstream platforms going to require age varification down the road, TT might be the only viable platform where anonymity is still a thing.
Regarding the official iOS TT app it seems that a new update, v5.22, have just been pushed out but from the changelog it's nothing more than adding a new translation, easy login and a bug fix.

By Casey Reeves on Wednesday, April 8, 2026 - 08:13

Hi,
just used beta 7 this morning and it neither detected my loopback audio device nor my external headphones or airpods when connecting those. I had to quit the app and restart it again for them to actually show up. Still also has issue where if you plug in headphones and go into the audio settings it will will cut your audio so that others cannot hear you anymore until you restart the app.

Also hitting a very strange issue at random where the app starts behaving oddly without me dismissing the window and claiming that there are usable controls and yet no visible window all at the same time. Not sure why or what happens.

By Casey Reeves on Thursday, April 9, 2026 - 19:00

Hi, a friend of mine just hit a crash when trying to perform cmd+n to add a new server. He runs a mac mini with a m4 pro chip with an external display connected over hdmi -- not the apple one, to be fair.

Sounds to me as if there might be a race condition and a well hidden bug in TTAccessible code that might trigger this. Here is a link to the full crash report. Hope that helps to debug this problem.

By Mathieu on Thursday, April 9, 2026 - 19:37

Hi everyone, beta 8 addresses feedback from the thread and fixes a crash.

Download: ttaccessible-1.0.0-beta.8-1.zip

@Casey Reeves β€” The Cmd+N crash your friend hit on the Mac Mini is now fixed. It was a race condition during the server editor window layout. Also, there's now a Refresh Devices button in Preferences > Audio that forces the TeamTalk SDK to re-detect connected devices. This should help with AirPods and headphones not showing up.

@Johann β€” Subscription shortcuts are now just Control+number (and Control+Shift+number for intercepts) instead of Command+Control. Channels you haven't joined are now collapsed in the tree, and auto-expand when you join. The subscription menu items are also disabled when no user is focused.

@Matthew Whitaker β€” The nickname field issue is fixed. Clearing the field no longer snaps back to the old value.

If any of the bugs mentioned above are still present or if you run into new issues, please let me know β€” your reports are incredibly helpful. I can't test everything on my own, so thanks to all of you for taking the time to try the app and share your feedback. It really makes a difference!

By Johann on Friday, April 10, 2026 - 05:59

One annoying part of this is it keeps asking for my keychain passworld whenever I update to connect to servers, but I think it's because of the app being unsigned, right?
Also, can you add shortcuts for moving people, like the mulyt-select moving that is in the qt client, and shortcuts for kick/bann operations as well?
Also would love to have an option to disable the confirmation dialogs when trying to kick off a server.

By Quinton Williams on Friday, April 10, 2026 - 08:05

Hi.
First of all, I absolutely love having a macos teamtalk client which is fully accessible, so thank you very much for your work.
Regarding the bug, I noticed when I chose "both" for the "Single file (all voices mixed" option, the app doesn't seem to reflect the change. Additionally, the toggle for automatically starting recording doesn't seem to work either.
WHen I revisit this settings area, the changes do do appear to save, but I do suggest correcting this in the next update.

By Quinton Williams on Friday, April 10, 2026 - 08:11

One last thing, I can't figure out how to add custom sound packs. Is this supported, or am I missing something?

By Johann on Friday, April 10, 2026 - 09:07

Edit: OK, it seams the problem is with user voluumes I just checked and it's so weird, like my volumes are like, 20 for one user, 40 for another etc. I didn't even change it, this was on a fresh restart of the app, it seams to set random volumes for each user.
Isn't 50% supposed to be default, it mmight also be that when I adjust volume for one user it adjusts the volume for everyone or something.
Hey, over the passed few versions I've noticed the default 0DB master volume has gotten quieter.
And me on my friends always use the same mic gane on the server, so that's not the issue.
It's just that if I turn it up to like 5db, the recordings made the program would start distorting.
Also one more thing, can you add the command I shortcut to view user info?