ok great.
The question here is, can we target 10.9 while still supporting accessibility for people with newer OSX version.
If using feature in newer Xcode version while still using an older SDK would allow this, then this would be great.
I think it would be possible using the @available
keyword but as itās a compiler feature and not part of the SDK we have no way of checking whether itās available and supported in the userās build environment.
We are able to use it where we can guarantee that the Xcode version will be >= Xcode 9, for example in the new CoreMidi API which requires on macOS 11, but we canāt make that guarantee here.
I suppose notā¦ Iāll have to defer to the developer thatās struggling with this atm to provide more details.
if __clang_major__ >= 9
See ios - How to know the Objective-C language version in Xcode - Stack Overflow
?
That might be possibleā¦ Iāll look into it as it would be great to be able to support lower deployment targets without disabling accessibility support.
Thanks, Iāve added this to develop
here:
First of all, Iām really delighted to see this happening.
Iād like to draw attention to the fact that the open source NVDA screen reader is much more widely used on Windows than Narrator, see for example WebAIM: Screen Reader User Survey #8 Results for some evidence. Therefore it would be useful to include NVDA as a screen reader to test with on Windows.
I just checked out the develop branch and started projucer compiled with VS2019. I stumbled upon the following. As a disclaimer, note that Iām blind and therefore canāt verify what stuff looks like visually.
- When starting Projucer, in the templates tree view, all nodes are reported as expanded. Pressing left arrow on the nodes seems to collapse them, i.e. when I refocus an item, itās announced as collapsed. Yet, it looks like no event is fired to point out that the expanded/collapsed state has changed. Pressing right arrow is expected to expand the node if it is expandable, but instead focus moves to the next tree node. Furthermore, It somehow occurs to me that these nodes donāt have any children and therefore the UIA ExpandCollapse patternās ExpandCollapseState property should be set to ExpandCollapseState_LeafNode.
- When I land on the tree view with tab, the tree view itself seems to be focused, not the active inner node itself.
- When I tab from āOpen Existing Projectā¦ā to the template tree view, NVDA incists on announcing the top window āProjucer windowā. Iāve seen this in other plugins as well. This behavior doesnāt occur in Narrator, yet it is slightly annoying. Some quick debugging reveals that NVDA receives a focus event for the foreground window before the tree view itself gets focus.
- As already mentioned, it looks like the menu bar is not yet keyboard accessible.
setAccessibilityElement is only available on 10.10+ in modules/juce_gui_basics/native/juce_mac_NSViewComponentPeer.mm
Thank you for the detailed feedback! The data on screen reader usage is very useful. Weāll definitely look into testing with NVDA on Windows and Iāll investigate the issues that you have run into with the Projucer.
Thanks, both the PopupMenu and Label issues should now be fixed on develop
.
The following commit on develop
uses the @available
keyword when compiling with Clang 9 or above and should allow builds with deployment targets < 10.10 to use the accessibility features:
It also fixes the setAccessibilityElement
issue.
Iāve been trying to fit accessibility into my app and it all works fine, apart from sliders. There doesnāt seem to be any way to navigate to a slider without a text box other than with the mouse. And I have lots of these. Is there a way of dealing with this - wantsKeyboardFocus() doesnāt seem to help?.
Can you provide some more information? Are you just using standard juce::Slider
s? Iām able to navigate and interact with the sliders in the AccessibilityDemo using both Narrator and VoiceOver without issue.
It seems to me that juce still crashes on 10.9, here is the stacktrace for DemoRunner (crash on startup):
0 CoreFoundation 0x00007fff8bb1725c __exceptionPreprocess + 172
1 libobjc.A.dylib 0x00007fff902cae75 objc_exception_throw + 43
2 CoreFoundation 0x00007fff8b9cf9a6 -[__NSPlaceholderArray initWithObjects:count:] + 358
3 CoreFoundation 0x00007fff8ba33440 +[NSArray arrayWithObjects:count:] + 48
4 DemoRunner 0x0000000100a665c0 _ZNK4juce20AccessibilityHandler24notifyAccessibilityEventENS_18AccessibilityEventE + 176
5 DemoRunner 0x0000000100a60e99 _ZN4juce9Component24internalHierarchyChangedEv + 489
6 DemoRunner 0x0000000100a614e6 _ZN4juce9Component12addToDesktopEiPv + 1270
7 DemoRunner 0x0000000100b325ee _ZN4juce14TopLevelWindowC2ERKNS_6StringEb + 206
8 DemoRunner 0x0000000100a96054 _ZN4juce15ResizableWindowC2ERKNS_6StringENS_6ColourEb + 52
9 DemoRunner 0x0000000100aa7805 _ZN4juce14DocumentWindowC2ERKNS_6StringENS_6ColourEib + 85
10 DemoRunner 0x00000001002f8660 _ZN21DemoRunnerApplication13MainAppWindowC2ERKN4juce6StringE + 96
I think I see the issue there, can you try with the following patch applied and see if it resolves things?
0001-macOS-Accessibility-Fixed-crashes-on-macOS-10.10-whe.patch (4.1 KB)
It works, thanks !
Great, Iāll get that pushed to develop
. Thanks for testing.
Hello!
So as a user of VoiceOver on the Mac myself, having the accessibility built into the JUCE frameworks will be a game changer. Just looking through the apps that Iāve learned are built on JUCE as a framework, itās really amazing what could come of this. Iād love to help in any way that I can.
I wouldnāt say that Iām very good with code quite yet (Iām a novice in that area unfortunately), but Iād love to be able to test JUCE implementation in a more practical sense (like how it would work for me to integrate it into the projects I try and create). I realize that this probably has already been asked, but how can I, as a user, help? Are there parts of the branch that I can test on, or would I need to reach out to plug-in manufacturers themselves to sk for testing. Thanks again for making this happen, I CANNOT wait for this to be a reality. Well, I can wait, itās just Iām beyond excited for when it does.
I was using modified juce::Sliders, and had checked on the Widgets in the Juce Demo. I just went and checked in the accessibility demo. If you look at the rotary sliders and the single horizontal slider without a text box in this demo in VoiceOver, then you canāt navigate to them with Tab and they donāt show up in the list of objects when you hit VO-I. In addition if you use the mouse to select and modify the sliders, VoiceOver still thinks you are on the last button or text field. As far as I can tell there is an assumption that that the object has the keyboard focus, and this is just not happening for a textless slider.
This comes down to the difference between a focusable Component
and a keyboard focusable Component
which I explained a bit above -
JUCEās Slider
s donāt accept the keyboard focus so tabbing to navigate to them wonāt work and they will need to be navigated with the VO keys. The keyboard focus will stay with the last keyboard focused Component
until the VO navigation focuses a Component
which accepts it.
Iām not seeing this behaviour, if I use VO+I on the AccessibilityDemo
I can see all the sliders.