Menuitemradio or menuitemcheckbox is not announced, even though announcement is shown in NVDA Speech Viewer

[markmagennis]

Steps to reproduce:

1. Open NVDA Speech Viewer.
2. Go to the ARIA Authoring Practices menubar example https://www.w3.org/WAI/ARIA/apg/example-index/menubar/menubar-editor.html
3. Tab down to the Example and open the Font menu.

Actual behavior:

Speech Viewer shows:
"Sans-serif radio menu item checked 1 of 4
Font menu"

NVDA reads:
"Font menu"

Expected behavior:

NVDA should speak what is in the Speech Viewer, so it should say "Sans-serif radio menu item checked 1 of 4" before saying "Font menu".

System configuration

NVDA version:

2022.4

Windows version:

Win 11

Name and version of other software in use when reproducing the issue:

Firefox 108.0.2

This behaviour occurs if the first menu item is a menuitemradio or menuitemcheckbox. The same behaviour has been observed in my company's product but I cannot give access, hence showing that it occurs in the ARIA Practices example.

[Adriani90]

This is reproducible only in Firefox so far, and it is fixed when cancellable speech on expired focus event is disabled in advanced settings of NVDA.
However, disabling cancellable speech on expired focus events introduces other issues such as high verbosity on mouse movements, reporting of previously focused list items when focus event expired etc. So disabling this setting is not a suitable workaround.

Note: this issue is relevant only in focus mode. In browse mode the focus is not redirected to the first menu item, and is standard behavior in every browser as far as I can see.

cc: @jcsteh do you have any idea why the cancellable speech feature behaves differently in Firefox in this case?

[jcsteh]

I think Firefox is firing the event for the menu opening after the event for the menu item getting focus. We should probably fix that. There's https://bugzilla.mozilla.org/show_bug.cgi?id=731091, though that's not for ARIA menu items so we may end up needing a separate bug.

That said, NVDA could work around this like it already has for role="menuitem" with a tiny tweak to eventHandler.FocusLossCancellableSpeechCommand.isMenuItemOfCurrentFocus. Currently, this only checks for menu items. It should check for radio and check menu items as well.