[menu] When should activating a menuitem close the menu?

[josepharhar]

When activating a menuitem which performs an action, should it close the menu afterwards?

What about when checking or unchecking radio or checkbox menuitems?

[lukewarlow]

I think it maybe should depend on if they activate via enter or via space (at least that's what apg says)

[josepharhar]

Oh I didn't realize that this is already spelled out here: https://www.w3.org/WAI/ARIA/apg/patterns/menubar/

Thanks Scott, or whoever wrote this!

[scottaohara]

i did not write that :)

When activating a menuitem which performs an action, should it close the menu afterwards?

yes. that is the expected behavior.

What about when checking or unchecking radio or checkbox menuitems?

note that mention of the spacebar performing an alternate action is not actually reflected in any of the demos - nor is it behavior that is found, to my knowledge, in native OS menus. APG is not a standard, after all. the docs often align with how patterns work on the native OS's the roles are derived from - but the examples also sometimes go beyond that, and these won't always be fully agreed upon, or even things that have seen wide spread adoption. hence, this nuance on the "optional" bit...

i'm going to dig deeper into this topic / spit ball some ideas for consideration (not expecting they would all be what "needs" to be done)

I've referenced this topic/thread before - w3c/aria#2067 - but one reason you don't typically see menus with checkboxes (where it might be common to select more than one item at a time) veer away from the auto-close action, is because there's no good way (presently) to

1. indicate that this variation in behavior exists. not that there couldn't be - but it's currently lacking.
2. when using some screen readers, there's no real difference between space and enter keys. e.g., without a screen reader running, space does not activate a link - but with a screen reader running, it does - because it's effectively behaving like a mouse click/enter key press (to put it simply)
3. how does one signify they are done choosing items? they have to know the last item they want to check they need to press Enter instead of space? They need to press Esc? That commonly means cancel as well as dismiss. Will that undo their selections?
4. how does one signify they are done choosing items if they are not using a keyboard? Sure, one could click outside for light dismiss - but what about on a touch screen where someone has styled their menu to take up the whole screen at the smaller viewport size? (dismiss gestures could be provided for native elements - or android's back button. there are solutions that are available to HTML that aren't to ARIA. doesn't solve for all use cases, but things to think on).

Another idea is that being a native control - a UA provided close button could be added (and of course should be styleable). While buttons are not allowed children of a menu at this time - there's an argument to be made that if this pattern was standardized, and this button was provided by the user agent, then it could be treated similarly to the clear button of some text fields. It's there, people can click on it, but it's not in the keyboard order.

There could be discussions with AT vendors to help expose hint text for how to use multi-select menus. again, something that might be more possible with native implementations than with ARIA...

[josepharhar]

how does one signify they are done choosing items? they have to know the last item they want to check they need to press Enter instead of space? They need to press Esc? That commonly means cancel as well as dismiss. Will that undo their selections?

I think this applies to <select multiple> with a popup too, and I hadn't thought about it before. Native ones have OK and Cancel buttons.

[josepharhar]

The MacOS system menubar closes when toggling a checkbox and so does the menubar apg pattern example, and neither of them have ok/cancel buttons.

[scottaohara]

yeah. the ok/cancel buttons will be outliers, not norms. that's not to say they couldn't be useful - but i'd also submit that it'd be awesome to auto-provide such ui, rather than rely on developers to add it themselves, if this is a thing we want to provide consistent and good ux for