JUCE Accessibility Preview Branch

ed95 · March 24, 2021, 2:39pm

Hello all.

The JUCE team is delighted to announce that a beta release of accessibility support in JUCE is now available on the new accessibility feature branch: GitHub - juce-framework/JUCE at accessibility

Please use this forum thread to provide any feedback about the new feature.

Please also help us spread the word. Whilst we have links to a number of groups within the audio industry who we know are particularly interested in this new functionality, any feedback from developers and users who have previous experience with accessibility features would be very valuable.

Accessibility support will be part of JUCE 6.1 (so included within the scope of a JUCE 6 licence), where 6.1 will be released once the accessibility support has been thoroughly tested by the JUCE community.

This initial release of accessibility support targets macOS and Windows. Additional platform support will be evaluated following the initial release.

JUCE software built against these changes will be accessible by default on supported platforms so we strongly advise everyone to test how their products behave under VoiceOver and Narrator using this branch so there are no surprises when its released.

A brief overview and “Getting Started” guide can be found in the docs/Accessibility.md file and a talk from ADC 2020 on this topic can be found on YouTube at https://youtu.be/BqrEv4ApH3U.

ed95 · March 22, 2021, 4:43pm

TeotiGraphix · March 22, 2021, 6:07pm

Wow. I was just talking to some people on the TAP Discord the other day about this very thing!

Kudos for bringing accessibility in!

jpo · March 22, 2021, 6:11pm

First of all: this is awesome.

Many of my UI buttons perform a different action whether they are left-clicked or right-clicked/long-clicked. How would you recommend to make the right-click/long-click accessible ? The list of AccessibilityActionType is short, so I wonder how I would associate two actions to a button component. Maybe create an invisible “ghost” button that handles the right-click ?

Also, a more general question : I have absolutely no idea of how to test accessibility on macos and windows. Do you have links to documentation that explains that ?

ed95 · March 22, 2021, 6:27pm

The accessibility actions reflect what is supported by the screen readers on both platforms (VoiceOver and Narrator), which as far as I am aware only support simple “press” actions for invokable UI elements like buttons. When designing software to be accessible I think it’s best practice to avoid complicated UI actions and keep it fairly simple and intuitive - it would be hard for a user with visual impairments using screen reader software to discover that your buttons perform different actions on long-presses for example.

As for testing, if you open System Preferences->Accessibility->VoiceOver you can enable VoiceOver and also using the training and utility guides for learning how to get started.

jrlanglois · March 23, 2021, 5:08pm

This is fantastic!

The one (larger) thing I’m most curious about is mobile support. What challenges and considerations are lurking there?

In the meantime, I’ll pull down the branch and give it some tests.

g-mon · March 23, 2021, 5:33pm

I just re-compiled my plugin plugin against the accessibility branch. So far, “it just works” with voice over. I can navigate all the knobs, buttons, etc. One thing that isn’t immediately obvious is when it reads the component name vs the component text. For example, I have a lot of buttons with just an icon and it just reads “button” for them, I’d expect it to fall back to the component name if there is no button text. For other components always seem to read the component name.

I need to dig into this a bit more, but so far it’s promising.

ed95 · March 23, 2021, 5:40pm

We’re currently investigating what’s required for mobile support. iOS is broadly similar to macOS, but Android will require significant work.

ed95 · March 23, 2021, 5:45pm

AccessibilityHandler::getTitle() is what will generally be read out by the screen reader when it focuses on a UI element. For the default accessible Button implementation in ButtonAccessibilityHandler this just returns Button::getButtonText(), but it might make more sense for it to use a fallback as you suggest.

github.com

juce-framework/JUCE/blob/e65c1d07a2e9e2b8a80eb62dd6374c355f976d31/modules/juce_gui_basics/accessibility/widget_handlers/juce_ButtonAccessibilityHandler.h#L59


        {

            state = state.withCheckable();



            if (button.getToggleState())

                state = state.withChecked();

        }



        return state;

    }



    String getTitle() const override  { return button.getButtonText(); }



private:

    static AccessibilityActions getAccessibilityActions (Button& button)

    {

        auto actions = AccessibilityActions().addAction (AccessibilityActionType::press,

                                                         [&button] { button.triggerClick(); });



        if (button.getClickingTogglesState())

            actions = actions.addAction (AccessibilityActionType::toggle,

                                         [&button] { button.setToggleState (! button.getToggleState(), sendNotification); });

benvining · March 23, 2021, 10:19pm

OK, so if a user is using a screen reader to navigate a plugin’s UI, then should there be built into the plugin a feature that turns down the audio processing while the screen reader is speaking? Or is that something that the OS/host/JUCE takes care of?

refusesoftware · March 23, 2021, 10:52pm

Counterpoint: public visibility was never an expectation of the names set by Component::setName. Having a fallback that suddenly makes behind-the-scenes stuff public is not a good idea.

Names could be confusing/unpronounceable (e.g. dBconvLin2) or even insulting (idiotButton1)…

ImJimmi · March 24, 2021, 9:18am

Although I agree it’s not ideal to reuse a feature that was never explicitly intended to be user-facing, I can’t help noticing that the examples you gave are more like IDs than names so they should probably be set using Component::setComponentID(), not Component::setName().

asimilon · March 24, 2021, 10:53am

Every day seems to be a TIL with JUCE, even after 3 years of nearly daily use
I was also (ab)using the name for ID like usage.

SomeSortaPotato · March 24, 2021, 1:03pm

Heylo. Formerly normal-sighted totally blind dude here. This is a huge deal for me and the blind audio pro community. If anybody needs a beta tester with tech comprehension and major respect for devs’ attention to my community, let me know!

To throw my hat into the ring here, I gotta say, I’ve found that buttons’ labels don’t have to be super user-friendly in name. As long as it’s labeled somewhat, we blindies manage.

I have/use two Macs, a 2018 Mini and MacBook Pro, an old iPhone SE, iPad Pro first gen, and my DAW is Pro Tools.

SomeSortaPotato · March 24, 2021, 2:30pm

Good looking out @benvining. I’d say that it’s best to have full volume.

On Mac we can press VO modifier+command+shift to access a menu with VO volume.

Another thing that I do is using the built in sound card with its own speaker or physical headphone mix channel for VO speech, with daw playback going through my interface and monitors.

*I derped on the modifiers, it’s muscle memory these days. Edit clarifies it’s VO+command+shift

ed95 · March 24, 2021, 3:02pm

An important point to note that I’ve just added to the OP:

JUCE software built against these changes will be accessible by default on supported platforms.

This means that as of the 6.1 release, JUCE apps and plug-ins will be accessible to the VoiceOver and Narrator screen readers, so it’s a good idea to use this preview branch as an opportunity to test how your software behaves and performs so there are no surprises when the changes make their way onto the main branches.

Since the changes are mostly behind the scenes and should “just work” by default we don’t anticipate this requiring a huge amount of work and it may also expose UI/UX issues that should be addressed regardless. We also think that this is the right thing to do, since it will enable many more JUCE-based apps and plug-ins to be accessible to users who require accessibility support.

jhomme · March 24, 2021, 3:09pm

Hi,
I do accessibility for a living. If you are a plug-in developer or just need to understand how accessibility is supposed to work, get in touch. I can test the accessibility of your plug-ins on Mac for sure, and I can get myself set up to do the same on Windows if necessary. I also can help you with IOS and Android accessibility if you need that. And consider your documentation accessibility needs. Consider doing your manuals in HTML or EPUB.

jhomme · March 24, 2021, 3:15pm

Hi,
The accessibility standards would like you to allow the user to tab to controls and use either SPACE or ENTER to activate them. Duplicate mouse actions with keyboard actions. If something requires dropping and dragging, you may need to visit the idea of either making sure that you don’t interfere with the ability of the OS to let keyboard-only users do that or construct alternate interfaces, such as a button to pick something up, a way to navigate with arrows and TAB, and a button to drop.

jhomme · March 24, 2021, 3:19pm

Hi,
I’m unsure of the languages and compilers you are using, but this guidance from Apple may steer you in the right direction. Apple Developer Documentation

refusesoftware · March 24, 2021, 4:31pm

@ImJimmi I agree about the preferred uses of component ID vs name, but the JUCE docs do not attempt to codify their intended uses anywhere. And as @asimilon illustrates, this confusion does not affect just beginners!

Add to it that there is a Component (const String &componentName) constructor, but not a similar one for initializing the componentID at construction time. So if you need only one set of identifiers for your components, you’re more likely to use a set of componentNames rather than componentIDs, since it’s more convenient to do so.

If the componentName is going to potentially suddenly becoming user-facing, then the docs for setName and getName need to at least be updated to mention this. Some further beginner-friendly verbiage in the docs about the intended uses of name vs ID would also be welcome.

Site navigation

JUCE Accessibility Preview Branch

Further Information