Juce Accessibility

With regard to accessibility on Mac, Pro Tools wins hands down. This is due to Avid working with Slau and choosing to fix Pro Tools and make it more accessible for Voiceover users on the Mac. Avid haven’t ask visually impaired customers for anything. They just chose to fix it as it’s the right thing to do. I don’t currently know of any other DAW manufacturer who has taken this approach.

I also fully appreciate that all developers work under tight time constraints and other priorities take over. Still Avid should be applauded for this. Avid treat accessibility as they would developing for any other language. Note: I do have pro Tools on the Mac but it’s not my primary DAW. Samplitude on Windows is and as we Know Samplitude Pro X3 Suite is around 96 97% based on Sequoia’s code base. Magix are also working with us to make Samplitude more accessible and we have scene some changes in Samplitude that really have made a difference.

The Reaper developers have also worked hard to make its UI accessible for screen reading software and I don’t think they have limitless funds either.

As for accessibility on Pro Tools not being as good as other options on Windows. That’s probably a debatable point as PT continues to improve in this area. Add to that Flo Tools:

And you have an extremely comprehensive solution.

Hi folks,

Just to join the discussion.

We here at Intermorphic put a great deal of work into making Noatikl accessible for iOS users. However, the only way we could find to do this, was to create it from scratch as a native iOS app (using Storyboards etc.) - where most of our apps had been Juce based. That has been a lot of work, but we’re happy with the end result. The new version of Wotja (which integrates Noatikl, Mixtikl, Liptikl) is also a native iOS app, and works well with voice over “by design”.

The reason we found this so important? Well, suffice to say that we had a number of requests over the years from blind and visually impaired users, for just such support in our tools, and I’m very pleased that we made the effort to do so. We’ve only had the resources to do this for iOS however; the macOS port of Wotja is not accessible at this point. Our user base has indicated to us that in general, iOS is “easier” for blind and visually impaired users that macOS, and certainly has much better support that Windows / Android - I don’t know if that remains the case case, but might indicate that it is better to focus on iOS to start with.

Of course, it’d be great if we could consider using Juce for future tools, but we don’t want to let-down our existing user base of blind and visually impaired users. If ROLI are able to “get started” with something in Juce which would at least let us use Voice Over support for iOS, that would be a tremendous piece of news for us, and we’d work with you as best we can to help you finesse this.

With best wishes,


Hi again,

I have a theory as to how this might be supportable on iOS and macOS (and, presumably, Android).

It might be a bit mad, but bear with me!

For every Component that declares itself as “accessible”, create a transparent (native!) associate UIView/UIControl or NSView/NSControl which floats over that Component (clearly, as Components are moved/resized/added/removed, these ‘invisible associate views’ would need to be moved etc., but that wouldn’t be impossible I’m sure).

This UIView/NSView is used purely for providing accessibility information. I’d presume that all touch/click events would pass-through.

Anyhow, that is it - but TBH, I’m not sure how else you could approach implementing this. I’d presume a similar approach would apply on Android.

Best wishes,


Yes, that kind of approach is probably the only realistic way of doing it. Definitely can’t promise anything soon though, it’s a large enough task that it’d need scheduling properly, and our roadmap is already pretty full for the coming months.

OK, thanks Jules. I’m sure you’ll keep us posted :slight_smile:

Would it be safe for us to assume that this will be done, but with (totally understood) no commitment on timescales?


At some point between now and the end of time, yes, I’m sure we’ll do it! But whether that’s months or years, I can’t say.

Well, I remain in hope!

Best wishes,


I believe that if someone can add a simple proof of concept implementation as an addition of one of the examples provided in the JUCE codebase, that will help the JUCE team to at least decide whether that may be a viable solution, or if some other direction should be considered

It feels like nobody on the JUCE team has done accessibility work before or worked with users who require accessibility features. The afterthought/evasive attitude towards including any sort of accessibility in JUCE is somewhat disturbing.

As stated by Apple in their accessibility docs:

You should make your iPhone application accessible to VoiceOver users because:

  • It increases your user base. You’ve worked hard to create a great application; don’t miss the opportunity to make it available to even more users.
  • It allows people to use your application without seeing the screen. Users with visual impairments can use your application with the help of VoiceOver.
  • It helps you address accessibility guidelines. Various governing bodies create guidelines for accessibility and making your iPhone application accessible to VoiceOver users can help you meet them.
  • It’s the right thing to do.

Emphasis on the last element mine - if ROLI/JUCE team is purely playing a numbers game (cost/time/etc.) by skipping accessibility, think of the tremendous impact it could possibly have given the massive amount of music software/plugins built with JUCE.

I’m off school for a few weeks for Christmas break, I’ll see what I can whip up per @yfede’s suggestion…


I wanted to chime in to this thread as well. I’ve had several blind customers to request JAWS as well and just got another one today. It would be good to consider.

1 Like

I’ve got a prototype with a macOS backend (which is also designed to be compatible with Windows later on) that’s around 70% done, and it’s pretty much drop-in as a module without having to modify JUCE code. So it’s on the way, whenever I get a bit of a break from school… :slight_smile:

It’s also going to be Apache licensed, so everyone can use it commercially!


This is extremely great news!!! :ok_hand:t4:

Thanks for sharing, Jonathan. Please let us know when you have something that we can have a look at!

I’ve become very interested in this subject over the past few weeks and months, but (as with many developers) never really needed to delve (or even consider) it in the past. (I’ll have to try an old Delphi VST I wrote).


I think you know how much respect for you I have, but I’m afraid his may be a tautology! No one’s requested it because the people who would request it can’t use it. People selling pluggins that don’t work for VI users don’t get used by VI users, and so you never get to hear from / meet them!
They’re too busy struggling with what they can use. They need and deserve better support.

I’m just now starting to grasp the enormity of the effort involved, but concur with what others have said here. (thought: as usual, I can’t help thinking there must be a simpler way, some carefully constructed messages injected into the OS message queue here and there, type thing (obvs different native ones) …or a means of posting messages to a separate “accessible” native app? but what do I know? )

I became interested after meeting a Blind drummer called Steve Burge at the London Drum Clinic a year or so ago (Steve’s a drummer and, in fact a drum tutor, and I might add, a damned fine one!).

Later I discovered that he was also a sound engineer and struggles everyday with the few tools that function in an accessible way (OSX/Protools/Screenreader…).

Last week Steve invited me to witness him at work, and I couldn’t believe what I saw… I now feel even more sure that this really must be addressed. As such, I’d like to offer Roli/JUCE as much time/effort that I can manage to help in anyway they see fit. Please get in touch.

Interestingly, some of the WIBNIs (Wouldn’t It Be Nice Ifs) that Steve mentioned (tabbing between items, programmable key commands, skins with High-Contrast/font sizes…) are already built-in… Steve did mention programmable Keyboard short-cuts and Menu options, too… and the ability to serialize them.

As @jonathonracz pointed out there are many good reasons… but as a JUCEophile, I see it as a chance to spread the word (no pun intended) and get even more cool JUCE-based apps (and many many more) JUCE-based app/plugin users, and customers! Think of those license sales, guys! :slight_smile:

Finally, I’ll add a very hard comment to make (especially, as I have an inkling of how much time, love, effort everyone’s put into developing JUCE to the point it is today)… Yes, it’s a big nasty time-consuming project to embark on… now, load your favourite JUCE project into your favourite IDE (I won’t be so cruel to suggest Projucer), switch your monitor off and get to work!


I’d be very interested to find out if JUCE developed plugins work with Keyboard Maestro (an automation/macro tool) with Flow Tools (https://www.ryansound.net/flow-tools) on Mac
and HotSpotClicker for JAWS For Windows (http://www.hotspotclicker.org/)
or JAWS, Job Access With Speech - (http://www.freedomscientific.com/Products/Blindness/JAWS) on Windows

I’ve tried it with NVDA & Narrator, but don’t have a recent OSX machine to test on

If anyone knows, it’d be very useful to know. Thanks

Would this be a good idea? Currently only Windows, but I imagine there might be APIs for OSX programs, too?


I had a meeting this morning with a senior manager at Apple who is very interested in Accessibility.

I discussed Wotja X with him, and told him how we’re now running on Juce, and explained to him how very much Tim and I would like Accessibility support (VoiceOver etc.) in Juce. He asked me if I’d expressed this to ROLI … I assured them I had…!

Anyhow, here I am again - do please try to find a way to add Accessibility support to Juce, it would be a great thing for very many people.

Best to all,



Thanks folks! I’ll look at those . Meanwhile I have a PDF version of the talk Steve Burge and I gave at the Audio Developers meetup this week - Sadly I can’t post it here (PDF not allowed :frowning: ) - but I’ll get it up, and re-post a link here. We’re hoping our talk will be added to the SkillsMatter page https://skillsmatter.com/meetups/10742-audio-developers-meet-up-april in due course (even though my laptop’s video failed) -

Meanwhile here’s a Youtube video demonstration of what a typical VI user has to cope with (includes a cameo by his guidedog!): https://youtu.be/Vfi3ilOGLCU


FWIW, my undergrad is just about finished, so I’ve started working on the accessibility module again. I’m simultaneously building a bunch of test scaffolding around it since I can already tell it’s going to be a pain to debug on multiple platforms. Hopefully I’ll have something to show off on macOS fairly soon!


This sounds like a really interesting project that could be really good for the community to get involved in. I would certainly be open to help contribute towards this. Although with a full time job and family I may not have as much time available as some :slight_smile: