Fix toolbar_toolbar.js by resetting menu button state

[howard-e]

Fix #3331

The menuitemradio elements have aria-checked set test now successfully passes in the CI and locally

---

WAI Preview Link (Last built on Tue, 19 Aug 2025 18:30:58 GMT).

[css-meeting-bot]

The ARIA Authoring Practices (APG) Task Force just discussed PR 3354: Fix toolbar test failure.

The full IRC log of that discussion

<jugglinmike> Topic: PR 3354: Fix toolbar test failure
<jugglinmike> github: https://github.com//pull/3354#js-repo-pjax-container
<jugglinmike> Matt_King: This is howard-e's pull request
<jugglinmike> Matt_King: howard-e can you explain the change?
<jugglinmike> howard-e: Sure. This is for the toolbar. There's a set of options that it opens. Those options can then be clicked
<jugglinmike> howard-e: This is just a quick patch, but I think there's something more pressing, here.
<jugglinmike> howard-e: This patch works because closing the menu again before trying to open another option
<jugglinmike> howard-e: I'm not sure why it works this way. I stepped back through the Git history, and the behavior is present there, too
<jugglinmike> howard-e: I can't replicate this normally; it's behavior we observe in the test
<jugglinmike> Matt_King: If you go to the APG and go to the toolbar and click a menu item, does it actually close?
<jugglinmike> howard-e: Yes
<jugglinmike> Matt_King: Is it closing when you operate it with a keyboard in production?
<jugglinmike> howard-e: Yes, it is. I'm not sure what's happening
<jugglinmike> Matt_King: So in the headless browser environment, the menu appears to stay open
<jugglinmike> howard-e: Correct
<jugglinmike> howard-e: The change here just checks to see if the menu is open
<jugglinmike> Matt_King: So this right here is just a change to the regression test code, right
<jugglinmike> howard-e: Yes
<jugglinmike> howard-e: I want to leave the issue open, though, to investigate further why it is like this
<jugglinmike> Matt_King: Can we get a reviewer on this pull request?
<jugglinmike> Adam_Page: I'll do that!
<jugglinmike> Matt_King: Thank you, Adam_Page
<jugglinmike> Jem: In the issue, it says aria-checked, but the pattern talks about a button with aria-expanded
<jugglinmike> howard-e: There is a button that's controlling the menu. It has an "aria-expanded" attribute on it.
<jugglinmike> Matt_King: That's correct; it should have "aria-expanded"
<jugglinmike> howard-e: The test loops through the options when the option is opened, and it clicks on one. It expects that aria-expanded should be set to "false", and that doesn't happen
<jugglinmike> Jem: But the issue says "aria-checked" and not "aria-expanded"
<jugglinmike> howard-e: The assertion itself isn't compromised; it's the way to get to the assertion
<jugglinmike> Jem: So can we ignore the assertion about aria-checked?
<jugglinmike> howard-e: Yes, that's fine
<jugglinmike> Matt_King: howard-e is saying that the fundamental issue is that we should need this workaround. Something it preventing "aria-checked" from being set in the test environment (and outside the environment, it works appropriately)
<jugglinmike> howard-e: That's correct
<jugglinmike> Matt_King: Okay, yes. This workaround bugs me, so I support digging deeper
<jugglinmike> Matt_King: I guess we might want to remove this change later if we can figure out why we need it in the first place
<jugglinmike> howard-e: I agree
<jugglinmike> Matt_King: Okay, then I guess we want a comment in the code reminding ourselves to remove it in the future
<jugglinmike> howard-e: I can do that
<jugglinmike> howard-e: This week, I'm going to try to prioritize doing the research here
<jugglinmike> Matt_King: Great. This points to a potential problem in the test environment itself

[adampage]

LGTM 🚀

[howard-e]

Hello @mcking65 this has an approval. So this can be merged while the core issue is investigated. Relevant comments have been left to remove the patch once it's properly resolved