🐛 [BUG] - Allow a declarative accessible label for the ActionMenu split-button toggle #1459

Describe the bug

In ActionMenu split-button mode, the menu toggle always renders with the hardcoded accessible name aria-label="Menu":

<Button aria-label="Menu" ... />

Consumers can provide an authored label to ActionMenu.Overlay, but there is no supported API for declaratively naming the split-button toggle. Updating the label after hydration is insufficient because server-rendered markup—and markup where hydration is delayed or fails—retains the generic name.

This is especially problematic when a ButtonGroup contains two split-button ActionMenus. Both toggles are announced as “Menu,” so screen-reader users cannot distinguish their purpose.

This is reproducible on current primer/brand main and in @primer/react-brand 0.74.0.

Reproduction steps

1. Render two ActionMenu components with mode="split-button" and distinct overlay labels.
2. Inspect the server-rendered HTML before hydration.
3. Find the toggle button for each ActionMenu.
4. Observe that both toggles render with aria-label="Menu".

Example:

<ButtonGroup>
  <ActionMenu mode="split-button">
    <ActionMenu.Button as="a" href="/mac">Download for macOS</ActionMenu.Button>
    <ActionMenu.Overlay aria-label="Other macOS downloads">...</ActionMenu.Overlay>
  </ActionMenu>
  <ActionMenu mode="split-button">
    <ActionMenu.Button as="a" href="/windows">Download for Windows</ActionMenu.Button>
    <ActionMenu.Overlay aria-label="Other Windows downloads">...</ActionMenu.Overlay>
  </ActionMenu>
</ButtonGroup>

Both dropdown toggles have the accessible name “Menu” until consumer-side JavaScript mutates the DOM.

Expected behavior

ActionMenu should expose a supported declarative API for the split-button toggle’s accessible name, and that label should be present in server-rendered markup.

For example:

<ActionMenu mode="split-button" toggleLabel="Other macOS downloads">

or an equivalent API on ActionMenu.Button/ActionMenu.Overlay that Primer can route to the toggle.

The API should:

• render the authored label during SSR;
• support multiple distinguishable ActionMenus on the same page;
• preserve existing behavior when the new prop is omitted;
• avoid requiring DOM lookup or post-hydration mutation by consumers.

Screenshots

N/A — this issue concerns the accessibility tree and server-rendered markup.

Browsers

Firefox, Chrome, Safari, Microsoft Edge, Opera

OS

Windows, Linux, Mac