Definitely. I want to have something at least sort of working before I share it with the world so it’s not totally useless and can act as a starting point for others. After that I’ll definitely want/need help with backend implementations on platforms I’m neither interested in nor knowledgeable enough to support (Android, Linux).
Here’s a Google Drive link to a PDF copy of our presentation.
We hope others find it useful/informative.
I just thought of a different approach to all this. I think retro-fitting JUCE to have invisible OS-widgets is the wrong way to do it. You’re basically just adding a translation layer, but keep the same layout and mouse-centric GUI you already have. This would represent a band-aid and not a real solution. You would only make it slightly better, but not really have an accessible user interface.
I’m currently in contact with two blind users. My new way of approaching this is to create a special user interface just for blind/visually impaired people. Nothing fancy, no meters, no eye-candy, no browsers etc. but just an array of OS-widgets that are all just buttons with text in them. The user can then tab/shift-tab through them, use space to turn toggles on/off, or use the cursor-keys (up/down) to adjust a value up/down.
It can be ugly as sin, and super-user unfriendly for sighted people, but for blind people it could be exactly what they need. The “browse” button should simply open an OS-level file-selector so the user can load the presets directly.
There should also be hot-keys for the most used functions (o to “open” a preset, f to toggle the filter etc.)
If JUCE could add a few classes to easily “build” these interfaces, that would be really great.
Once I talked to my customers about this and collected their requirements, I can share my findings here to continue the discussion. This could be a dramatic shift in accessibility and make JUCE the de facto standard for accessible user interfaces in the audio-industry.
a good example for accessiblity in a crossplattform framework is qt.io
i use qt for long time, but i would change to JUCE because it is more audio related then qt. but in JUCE i have no accessiblity support, and then all what i do is not accessible.
from qt: Qt supports Microsoft Active Accessibility (MSAA) and IAccessible2 on Windows, macOS Accessibility on macOS, and AT-SPI via DBus on Unix/X11. The platform specific technologies are abstracted by Qt, so that applications do not need any platform specific changes to work with the different native APIs. Qt tries to make adding accessibility support to your application as easy as possible, only a few changes from your side may be required to allow even more users to enjoy it.
It would be really nice if JUCE would support it out of the box, with no need of hotspot clicers or something like that.
it is 2018 now, and in lots of contries you have e.g. section 508 and EN 301, that makes the support for Accessiblity mandatory, otherwise you cant sell any product to e.g. schools or offical offices…
It would be nice to hear that MSAA or IAccessible2 … are in the dev roadmap of JUCE? because that can help me with the question what framework i take for my next projects.
I recently came across libui, which although fairly minimal in terms of skinning etc, could work very well for what @reFX is suggesting here. It should be fairly straightforward to wrap those C structs in C++ classes for use with JUCE.
Any update on where Accessibility sits in the JUCE roadmap?
As Gixxer says, it looks like this affects the ability to sell JUCE-based apps into various market segments.
I’ve been slowly moving to using React Native for most of my GUI, which comes with Accessibility features already baked in. I know ROLI is working on better integration with React Native.
It’s kind of hacky right now, but it looks very promising for the future. I can especially see how powerful JUCE & React could be together when the WebAssembly toolchain is a bit more mature. JUCE could incorporate react for a performant write-once, run everywhere framework that can target the web and have the same experience as native, with a modern UI system that 80% of developers these days are learning.
The methods I used in that tutorial are really out of date… there are much better ways to structure a project using JUCE and React Native. Plus at some point JUCE might have official support for RN projects…
My recommendation for now would be to create static library project with JUCE and add it as a subproject to a standard RN app. This will save headaches later, as you won’t have to deal with Cocoapods and you can use the standard tools that come with React Native.
All that aside, I’m personally more interested in learning how to do an accessibility make-over for a standard JUCE app. I know @ed95 had a go at this.
Has there been any progress with this?
@jonathonracz did you ever get your macOS solution to a releasable state?
Yes, but unfortunately my two blind beta testers haven’t replied to any emails since the prototype was finished.
The idea is that you simply add (with one line of code) parameters (toggles, “sliders” and text-editors) to a completely native GUI and then have a very simple, unified navigation system. There will also be hot keys to trigger specific functionality (e.g. open a file browser, next previous preset etc.)
It’s implemented for Windows and MacOS. Doesn’t need Juce or anything else and will be open source and free, once we’ve nailed the specifics down.
It will be hosted on github and MIT licensed.
We would love to invite people with experience designing for blind users or blind testers to try out the prototype. Simply message me directly, and we can talk.
Another blind musician here. I’m ready to help if I can, even though my skills in computer science is more this of a musician who, well, manages.
I’m using Samplitude as my main DAW.
So, what can I do to help?
I’ve tried to message you privately but haven’t found a way from this website,
Seems like an accessibility issue for the forum itself! For sighted users it’s super easy; click on the user avatar and there is a “Message” button. Somewhat ironic that this is a problem here!
So, how can I help?
Seems like new users aren’t allowed to send PMs, but I’m another blind producer here who’d be happy to test and provide feedback. I primarily use Windows 10 with NVDA and Reaper is my DAW.
Lemme know what would be most helpful to you.
Hi ReFX I also would like to help you beta-testing. I’m currently doing an audio-engineer-education at an institution that’s providing juce-based plugins. Being able to use this plugins would make life so much easier. I’m not a developer, but a quite experienced user on mac and windows. So what can I do?
Is one of the Beta testers one of the people who gave a talk at (the first?) Audio Dev meetup in London? (if so, I know he’s all-sorts of busy and has been for the past few months, but I’ve spoken to him recently (and passed-on this link) and he’s still very keen, if not a little distracted at the moment ).
Nice work! I will PM you to discuss further.
This is great! I’ll contact everybody who’s interested via PM (you should get an email, so you can reply to that) and there we can exchange email addresses to talk directly.
The first phase is nailing the user experience down so it’s as good as it gets. Currently, we applied our own “best guess” to keep the screen-reader chatter down to a minimum.
Once the user experienced is as good as we can make it, then we will seek input from developers how they would want to interface with the library. This will be a very fluid phase, where the API might change from one minute to the next. This process might take a while since we have only limited resources (read “time”) each day to devote to this.
We want to make the whole experience of creating and using these user interfaces as easy as possible for everyone. The aim is to lower the threshold of adoption. That’s also why it will be open source and MIT licensed. There is no need to mention us or the library anywhere (although it would be appreciated to guide other developers towards the project).
I wouldn’t know. Is he from South Africa?
To make things easier I’ve created a google group.
Simply send an empty email to
This group is intended for blind users to give feedback to our demo. Developer related discussions will later be handled on GitHub directly.