Currently the native mac menu bar implementation has functionality implemented to pass keyboard events to the currently focused component when the item is invoked by a keypress.
At first glance this seems reasonable, however according to Apples documentation both space and return/enter should invoke the menu item (and esc to dismiss the menu) https://support.apple.com/en-us/HT204434
Without any changes to the framework I could call
menuBarActivated is called with an argument of
true. This would however make accessibility worse in another way (loosing focus of the currently focused component). Again this could potentially be worked around by tracking the focused component and refocusing it in
menuBarActivated, to me this seems overkill for every application that has a menu that wants to behave in the expected way (and probably has some edge cases I’ve not yet considered). It seems from the history that
menuBarActivated may have even been added as a work around for this issue, see this commit https://github.com/juce-framework/JUCE/commit/b936786f802c930acd4427e20661b5a6b2c41ad8#diff-708184aa290335112694ecc5391dd448.
My first thought was that keys reserved for invoking a menu item should not be passed to the currently focused component. However investigating further it appears that these are the only keys that ever trigger this method in the first place! Therefore I think it’s only right that I challenge the section of code altogether.
I respect removing the relevant section would be a “breaking change” but as far as I can tell it would be one that improves accessibility and general consistency of behaviour with other apps on macOS. I don’t think it’s OK that every application has to actively work around this in order to have a functioning native mac menu (for all users). However I do think it’s acceptable to take a stand against supporting a native menu that breaks accessibility.
The issue has been raised before in 2015 (Mac Native Main Menu keyboard handling), Fabian’s suggestion at the time again seems reasonable, but then the component receiving the key press would have to determine if the key press was from a menu or not. This is possible but it doesn’t feel like this it’s something components should be responsible for.