MenuToggle does not derive accessible name from visible text children

Description

When MenuToggle renders with visible text children (e.g., <MenuToggle>Actions</MenuToggle>), it does not automatically derive its accessible name from that text. Consumers must manually duplicate the text in an aria-label prop, which is error-prone and violates WCAG 2.5.3 (Label in Name).

WCAG Impact

• 2.5.3 Label in Name — For UI components with visible text labels, the accessible name must contain the visible text. If MenuToggle doesn't derive its accessible name from its children, speech-input users who say "click Actions" may not activate the correct control.

Steps to Reproduce

1. Render <MenuToggle>Actions</MenuToggle> without an aria-label
2. Inspect the element's computed accessible name in browser DevTools or a screen reader
3. The accessible name may not match the visible "Actions" text

Expected Behavior

MenuToggle should derive its accessible name from its text children by default, similar to how a standard <button>Actions</button> does. An explicit aria-label should only be needed for icon-only toggles (kebab menus).

Current Behavior

Consumers must manually provide aria-label="Actions" even when the text "Actions" is already visible in the toggle. Our codebase (ansible/ansible-ui) has hardcoded fallback aria-label values like 'kebab dropdown toggle' and 'dropdown toggle' that don't match the visible text, precisely because the component doesn't handle this automatically.

Jira Issue: PF-4545

Commencez par le composant MenuToggle et examinez comment son nom accessible est calculé lorsqu’il reçoit des enfants de texte visibles sans aria-label. Comparez ce comportement à celui d’un bouton standard et déterminez comment les libellés explicites doivent se comporter pour les toggles composés uniquement d’une icône. C’est terminé lorsque les enfants de texte fournissent par défaut le nom accessible, tandis que les valeurs explicites de aria-label restent disponibles pour les toggles composés uniquement d’une icône.