Improving accessibility of the mac menu bar

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)

Without any changes to the framework I could call juce::Component::unfocusAllComponents() when 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

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.


Yes, passing these key events to the focused Component is the wrong thing to do here and I agree that removing this altogether is the best solution (even though it is a breaking change). We’ve added that to develop here:

We’ve also added a couple of improvements/fixes to PopupMenu to make it more accessible for keyboard navigation here:


Amazing thanks @ed95! I’ll check these out first thing next week.

1 Like