JUCE Accessibility on `develop`

You don’t need to figure out a way to solve the issue of balancing DAW and screen reader output @benvining. Screen reader users can handle that for themselves, and it’s best that they continue to, because the most productive setup changes from person to person. For example, I like to have my screen reader talking through a totally separate tinny little speaker on the desk that sits in easy reach, and for certain tasks (EG dialing a high pass filter to taste) I often mute the screen reader temporarily so as not to be distracted by the numbers, whereas if I were selecting an output from a dropdown menu, the screen reader would stay on because I absolutely need to hear those choices. By way of contrast, a singer/songerwriter I’m tutoring later today finds my workflow to be discombobulating. For her, my rig where the speech is coming out of a separate speaker is hella distracting. She finds the presence of speech feedback in combination with the audio from the DAW to be reassuring, and prefers to have the OS handle ducking the DAW when the screen reader is chatting. BTW, each OS already provides optional auto-ducking functionality if that’s the approach a user wants to adopt.

Hope that helps. Super excited to see where this goes!

If there’s anything I can do to help test your plug-ins (Reaper user who’s comfortable on bleeding edges in Windows and Mac here), don’t hesitate to drop me a PM.

5 Likes

@ed95 The Component::createAccessibilityHandler is marked as private, presumably that should be protected?

No. Marking it private allows derived classes to override it, but prevents it from being callable by derived classes. Accessing a Component's AccessibilityHandler is done via the Component::getAccessibilityHandler() method.

That does help, than you for the info!

1 Like

What I’d quite like would be to have some means of added a custom handler, or falling back to the default for that class, on a component by component basis

Something like this gist

Please don’t think I’m requesting this be possible, this is more of a “this is what I’d like to do, do you have any thoughts/suggestions?” type thing

Hi. I am glad that the new owners of Juce is finally getting things on the road to making the framework accessible. As Juce is very widely used to develop vsts and audio related applications, and as a blind musician and programmer myself, I have looked forward to this day since I brought the topic of Juce’s lack of accessibility up for consideration some years back. I knew then that Juce had many potentials, but that the conundrum was that a specialized framework for audio development and production was not accessible for use by people like me who depend a lot on audio, both for music production and for use with the PC. The blind community of musicians are excited and are waiting for the day when audio related applications such as audio interface controllers, vsts and plugIns related to music can be independently accessed without the need for sighted input. Thanks to all concerned for this. One question: Will Juce be made available for Microsoft’s Vcpkg Installation eco system? I ask because it would be that much easier to have Juce intigrated and ready to be used with Visual Studio. I have tested the framework’s accessibility with VoiceOver and narrator, and it looks promising. There are two other major screen readers, NVDA and Jaws. I should think that it would not be very difficult for Juce to be made Accessible for those as well. I will extend my help if it is needed. Thanks once again. Cheers!

1 Like

@ed95 just wanted to thank you and the team for getting on with this.

This has been a long wait, but I’m really glad you’ve carved time out for this, from of what is no doubt a very tight development schedule :slight_smile:

We have blind / visually impaired users still using Wotja 5 (which was our last native implementation, with voiceover support for iOS and macOS); all on iOS devices now rather than macOS if that is of interest. They’ll be very happy as and when this is available for newer versions of Wotja for iOS! We’ll also get very good feedback from them, to tease-out any issues.

Best wishes,

Pete

This is amazing news, well done JUCE team.

I look forward to checking this out and testing with our products in development.

FR: On Windows and macOS, buttons with keyboard focus can be triggered with the spacebar. Please support this in JUCE as well.

1 Like

Here’s some observations from my first exploration of the Projucer GUI built with the accessibility branch included. I attempted to use the keyboard for all interactions, with Narrator providing spoken feedback in Win10. I poked about in the window that comes up when Projucer first opens, and should probably apologise in advance because I’m not very familiar with Projucer terminology yet. Issues listed in order of severity for screen reader users.

  1. ON first launch, I’m able to navigate a tab order (albeit a fairly scant one) using Tab and Shift+Tab. However, if I visit the menu bar then return focus to the GUI by hitting Escape, the tab order is no longer navigable. This is a biggy because in Windows, tab orders are the bread and butter of navigation for most screen reader users.

  2. The menu bar can currently only be reached by navigating the object hierarchy. Longstanding keyboard convention in Windows is for Alt to move focus to the menu bar, DownArrow/Enter to expand menus, and Escape/a second press of Alt should both return focus to the GUI (ideally to the most recently focused control).

  3. Narrator currently reports rows and levels as I move through the tree view on the left, but doesn’t report the functionality associated with each choice yet.

  4. The Project name edit field has no accessibility label defined yet, and although I am able to navigate within the edit field using Arrows as expected, Narrator doesn’t report the cursor position changing or any edits I made to the text I’d inserted.

  5. The button to set project path is currently labeled “…”. Many screen reader users will hear this as an unlabeled button, because it’s commonplace for intermediate users on up to set reporting of punctuation to either Low or None. Could “…” be changed to “Browse” to improve clarity?

That’s probably about enough for now.

@ed95, is this thread the best place to report findings, or would you prefer issues to be filed directly on the accessibility GitHub branch? I’m easy either way. :slight_smile:

Cheers,

Scott

5 Likes

Pop me down as a large +1. Would also be good if - on Windows - Shift+F10 and Applications key could be supported as keyboard equivalents for right-clicking the focused control. They’re both longstanding conventions that screen reader users are familiar with. Thanks!

FR: juce::ToggleButton should read if it’s checked or not. It’s not currently on macOS, where as the system check box do.

Thanks for the detailed feedback! We’ll look into these issues that you mentioned.

Yes please continue to use this thread for feedback, it’s good to keep it all in a single place.

FR: Tab order in JUCE is weird that it uses x,y position. Since buttons tend to be a bit taller than text edits, to the user, tab order appears to bounce around randomly. Please add an option to have Windows style z-order based tab ordering. Or move the tab order sort function into the look and feel. Some way to easily change this without having to reimplement the focus traverser or manually set it for each Component.

2 Likes

FR: You should be able to adjust slider value with the keyboard when it has keyboard focus

4 Likes

HI JUCE team, congratulation on this great milestone!
I built GainPlugin_Standalone on MacOS, and the generated app was accessible! Awesome!
Then I built GainPlugin_AU, but VoiceOver wasn’t able to find the gain parameter in the regular plugin view in Logic. The gain parameter did show up however in controls view.
Can Logic render Juce UI accessible to VoiceOver in the regular view?
Thanks!

GainPlugin_VST3 was accessible on Reaper!
Maybe the UI elements of JUCE is not being included in the accessibility tree of Logic plugin window?
I’m not sure if JUCE can grab the parent window presenting JUCE gui and insert itself into the accessibility tree, or if this is something that Apple has to fix.

String ListBoxModel::getNameForRow (int rowNumber) { return "Row " + String (rowNumber); }

This should probably be rowNumber + 1, most users don’t count from 0. Also, it’s getting the total number of rows incorrect for me. For example it’s reading “Row 4 (6 of 19)” when there are only 15 rows.

How do you recommend handling a slider that goes from 0…1 for example, but controls a parameter with a different user visible range? The valueFromTextFunction and textFromValueFunction aren’t used in the AccessibilityRangedNumericValueInterface.

String getCurrentValueAsString() const final { return String (getCurrentValue()); }

This seems like a bad way to do it. User does not need position of knob to 6 decimal places, and doesn’t seem to be any way to override this function.

BR: Accessible plugins crash if they open a window.

[window setAccessibilityLabel: juceStringToNS (JUCEApplicationBase::getInstance()->getApplicationName())];

You can’t assume JUCEApplicationBase::getInstance() returns a valid pointer, since it returns nullptr in a plugin.


BR: On Windows, Narrator get stuck on Slider popup. As I tab through controls, narrator keeps up and tells me what the current control is. When I mouse over the Slider, narrator moves to the slider popup, and stays there once it’s gone. As I continue to tab, narrator is stuck on a non-existent component.

Video: Narrator - YouTube


BR: If my application window has focus, tab doesn’t seem to move the focus from the window into the juce components


Forum won’t let me post new messages, so adding additional bugs to this comment.

1 Like