It doesn’t matter what you toggle the state to. It always says “deselect toggle” - there is no reporting of the state. Seems like a bug to me… or do I really have to write my own custom Accessibility handler?
It should at least say “select toggle” and “deselect toggle”.
Contrast this to Reaper and others, where they have role of “checkbox”, and it correctly states “check checkbox” and “uncheck checkbox”. You know the present state of the object. And a checkbox is a checkbox. Using VO on one of Reaper’s checkboxes:
So far I haven’t been able to reproduce this issue. I used the project provided by you, tested on Monterey 12.6.2 and Sonoma 14.1 Beta 2. Also ran both the Standalone and the VST3 versions. The text VO gives me is always You are currently on a toggle button. To select or deselect this tickbox, press Control-Option-Space. The current state is then correctly reported.
What OS version are you seeing this issue on?
How often does it happen? Does it work correctly sometimes?
Any tips you can think of for triggering this behaviour?
The version I reported this for above is (sorry) Mojave 10.14.6. My main studio machine is old and that’s what I’ve been working on mainly for this whole project so far.
And yes, it seems to do it all the time, although sometimes you can manage to get different results out of VO regarding the path of navigation it seems. But not the “deselect” wording.
But I went ahead and tested the same example above on my laptop, which is still behind the times, but at Big Sur 11.7.7. With Juce 7.0.7 release.
Interestingly, the results are slightly different. It doesn’t say “select” or “deselect” at all. It just repeats “toggle button”. No state.
Also, I find that it doesn’t always do the same thing, in the same order.
But here’s what I get most of the time. Follow this exactly:
add an instance of the AccessibilityToggleTest plugin to the APH staging area.
Turn on VoiceOver using keyboard commands (ctrl+F5). Double-click the plugin to open it. It focuses on the close button and says this:
Press ctrl+opt+right arrow and it moves to the inner container. I also specifically have a question about this behavior, because 9 times out of 10, VO beeps but it says NOTHING. And the currently displayed text remains where it is: See this thread. Why doesn’t it report the name of the container? Or something?
As long as I have your attention, this is the other thread where I was asking about the container weirdness. But this may only be an AudioPluginHost thing, as it does not work the same way inside Reaper for example.
A fix has been released on develop which corrects the behaviour of the radio buttons.
It also affects the behaviour of the ToggleButton, and while I haven’t reprod the issue yet, there’s a good chance it will at least affect those issues as well.
Can you see please if the ToggleButton now behaves properly?
I’ll also try to address the empty group behaviour in the AudioPluginHost, but that’s proving a bit hairier.
I think the different behaviour across OS versions is really down to differences in VO’s implementation.
Recompiling APH should not be necessary.
There’s nothing on the public JUCE API that you could use to make it a checkbox. If you were to comment out the line returning NSAccessibilityToggleSubrole in juce_Accessibility_mac.mm then it would become a checkbox in VO.
This is something we could consider as a feature request, but it would have to be done in a way that’s consistent across all platforms.
It still seems strange that on Big Sur, there is no reporting of the unselected state when you toggle back and forth. But ok, I understand it’s not a feature many people use.
I would definitely suggest you add a checkbox role, if that is what is required. This is the same system, Big Sur, showing an Apple checkbox. It accurately reports it as a checkbox, and “checked” and “unchecked”:
