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…

Request: ComponentPeer Listener

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.


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!