Hi Everyone. To Introduce myself, My name is Jaffar and I am a blind software developer from Singapore. I first came across Juce about 6 months ago, but because of my work commitments didnt get to try it out until today. However, though I am aware of it's power and versatility, particularly in the field of audio application development which is naturally geared towards the blind and visually impaired computer user as it allows for another auditory sense to be enhanced as a replacement for the lack or absence of sight, Juce itself as a development tool which should help in this area is virtually non-accessible. As an example, I depend on a screen reader, Jaws for windows, and VoiceOver for the mac to navigate my computer's screen and to inform me as to where i am in a certain application's menu or to read my emails and vavigate websites and to develop my apps. Indeed the very reason as to why I am communicating with users of this forum right now is through vocal output from my screen reader. However, for example, my screen reader is unable to interac with Juce's Introjucer project building application, and because of this, i am unable, say, to use Juce with vs or any other apps which would take advantage of Juce's audio application building capabilities. So I wonder if this issue can be looked into, and I'd be willing to contrebute my effots in this direction. Thanks for hearing me out and cheers!
It's a tricky one for us, because JUCE's main user-base has always been about highly customised, graphical interfaces, like plugins, which tend to have very odd mouse-interaction behaviours, and I don't think we've never actually had any requests for accessibility features before.
It's certainly important, and is something that has always been lurking in our backlog, but can't make any promises about how soon we'll have time to investigate it. Of course if you have experience with the accessibility APIs and can suggest anything that would be an easy win for us, please let us know!
I have just had a request from a customer about implementing some basic accessibility for the blind, so I'd like to lend my support to this idea. We make audio software, and it's natural that the blind will want to use our products.
As I understand it OS X has a fairly good accessibility API, the docs are here, is there any way to hook JUCE into that?
Yes, all the OSes have APIs for this, but it's a non-trivial job for us to create our own API that abstracts all of them, and implement/test it on all platforms. I honestly don't think there's any chance that we could even consider this for at least the first half of this year.
If we manage to find some great new coders to join the juce team soon, then we may have more chance to look into things like this, but we're really stretched for resources right now, and already have a ton of higher-priority things to do!
Are there any updates regarding JUCE and accessibility? This is one of the major cons of the otherwise excellent framework. In theory the screen reader merely needs to be able to read label text (or alternatively there could be an optional screen reader text attribute for each component) . If the application or plug-in is properly implemented, it should be possible to use tab and key combinations to adjust parameters, edit text, etc.
Sorry, it hasn’t managed to fight its way it onto our priority list this year…
I agree it’d be great for us to do, but the commercial reality is that when we try prioritise our huge list of requested features, this one is always stuck in the awkward position of being very time-consuming and expensive to write, and also being of little or no interest to most of our customers…
Thanks for the update, Jules. I hope you can find the time to look into this in the future.
I’m a blind musician from Paris France. I’m 56, started with the piano, then moved to analogue synths, then to FM, then to sampling, and had no particular accessibility issues until computers got in the way.
It’s a brand-new world, and the first one where blind musicians are really disadvantaged.
we have screen readers of course. Windows has two, a free one called NVDA, and a paid one called JAWS, which has more functions and can be used with DAWS like sonar Reaper and Samplitude very efficiently.
Apple had enough money to invest in making OS X and iOS accessible for free.
Juce is not Apple of course. And I can understand their concern about requests priorities and profitability. Nevertheless, we suffer and that’s unfair. It is not Juce fault, but that’s unfair anyway.
So how do we move? Some small companies like Izotope, I don’t know how and why, have made some of their products screen reader accessible.
If Juce could include an accessibility module in their libraries, that would give all their clients the opportunity to give a chance to the visually impaired to buy and use their products. That may not be a lot of money, but that would be fair wouldn’t it.
Think that for the moment, plug-ins like Pianoteq and the UVI player, are things we cannot use without someone to assist us, even for things as basic as loading sounds.
So the question is, how much money does Juce need, and how do we get it?
I know JUCE is all about being cross-platform, but a possible answer is to just support accessibility features on macOS/iOS since from what I understand they’re lightyears ahead of what Windows/Linux can do.
This would eliminate the need for feature parity/lowest common denominator implementation. Additionally, as has been said Apple actually cares about accessibility in their products so I would guess a majority of disabled users (especially disabled musicians) would benefit from this (since a sizable population of them use Apple products due to their better support).
The pushback on adding any sort of accessibility to JUCE, even basics like screen reading, is understandable from a short-term pure business standpoint (not having to put in the effort) but really disappointing none the less.
HI. I would like to bring to your attention two cases where accessibility has been implemented for: 1. an application. 2. a hardware/software synth. Heard of Magix Samplitude? I don’t know how big or small this software company is, but when a few of my blind counterparts brought up the possibility of adding accessibility for blind users to their Samplitude DAW app, they were willing to sit down and consider the possibility. Much work then ensued, and because developers at Magix were willing to make changes to Samplitude’s UI, scripts for the Jaws screen reading software have now been written so that blind musicians like us can use their application with a huge amount of freedom which in turn allows us a great degree of independence in music making and recording. 2. Native Instruments. Again I don’t know how big this company is, but they have gone a long way towards making their hardware keyboard and soft synths very accessible. Just by connecting the hardware synth to a Windows or Mac pc, and installing the software, voice output is possible just by turning knobs on the hardware synth itself. Yes there are priorities, and yes there is the small matter of cost to be considered, but as these two examples demonstrate, such obstacles and challenges can be surmounted if both parties will sit down and consider the pros and cons objectively. I wouldn’t be posting my thoughts here if I didn’t think that Juce, or even Roli for that matter aren’t fantastic products in their own right. Juce is a tremendous application, Roli is a tremendous Keyboard. Now if blind musicians like us can have access to Juce’s and Roli’s features at our fingertips, literally, wouldn’t it be great, both for us the blind musicians and programmers and for you? Thanks.
Well, you might be surprised. Some of us like the PC better. The reason may be that we have been used to it for a long time, but the fact is, with a paid screenreader like Jaws, , a DAW like Magix Samplitude is almost 100% accessible. ProTools and Logic on Mac has not reached this level of accessibility yet.
So, I really think that Juce should keep its multiplatform philosophy, and implement accessibility to all. Anyway, once they do the job, I don’t think it will be less work to do it only for one system.
Thank you Jean-Philippe for voicing the needs of the community of blind musicians. We are listening and have looked into the complexity of supporting accessibility. This is not a trivial task, and we would welcome support from the community to help make it happen faster.
If developers who are listening here have implemented screen readers on top of JUCE and are willing to share their work with the community, please get in touch!
I have no idea, how the preferred ways are to use a GUIs without sight, but would spoken tooltips make any sense? That could be easily integrated into the TooltipWindow class.
Sure, that is not the solution for everything, but may serve as an easy interim solution, until a better workflow can be established?
Very glad to hear that you are looking into this, JB!
No promises there as it could easily become a heavy task to support screen readers on all platforms, but we’re keen to support an experimental phase, especially if the community can provide code to help us get started.
Might be worth contacting NVDA as they’re the closest to juce by being open-sourced.
They might be able to contribute.
I’m wondering if it would be easier to hook up to the speech synthesis APIs directly and bypass the screen readers?
Having to post this here as there is a 3 post limit for new users. That’s a sure way to shut down the accessibility discussion isn’t it I wonder how you get that limit lifted?
Anyway, hmm. Integrating into the TooltipWindow class. An interesting approach. That’s not going to help with opening menus etc. Further more in the case of the Voiceover screen reader on the Mac, it can either see things or see nothing at all and if it doesn’t see anything then it literally sees nothing on screen. That’s one advantage being on Windows as you can do a bit of screen scraping (definitely not recommended) or OCR the screen which also slows down productivity.
What would be good though if there were some way to easily expose UI elements in Juce on Windows and Mac. For example. Currently in the UVI player if you double click in the brows Window that opens an inaccessible browser. It would be great if there were some way for developers to code it so that instead of that opening an inaccessible browser it used a standard Windows UI such as Windows Explorer on Windows or Finder on the Mac. Similarly if a menu in an interface needs to be clicked then instead of using a Juce UI menu, the interface could use a standard OS UI element.
I have no idea what apps such as Superior Drummer 2 used to code up the UI however I do know that because the UI both on Windows and Mac exposed standard menus when clicked on this meant that I was able to build an accessibility solution using HotSpotClicker on Windows with the Jaws screen reader:
and Slau was able to duplicate something similar on the Mac using Keyboard Maestro and build that into Flo Tools.
I think the truth is that Apple cares about Apple. My reason for saying this is that if Apple really cared about accessibility then Logic would be the most accessible DAW on the planet for anyone using Voiceover. Fact is it is not. As pointed out else where on this thread all OS’s have API’s that can be utilised with regard to addressing this particular issue.