[EuiContextMenuItem] Add hasAriaDisabled prop type

[brunofarache]

Summary

• What: Declares the hasAriaDisabled prop on EuiContextMenuItemProps and forwards it explicitly to EuiListItemLayout. Also adds the missing focusEuiToolTipTrigger declaration to the published test-util types.

• Why: hasAriaDisabled (#9214) already worked on EuiContextMenuItem at runtime — it fell through ...rest into EuiListItemLayout, which declares the prop, performs the disabled → aria-disabled swap via useEuiDisabledElement, ships a dedicated disabled style, and keeps the item focusable so a toolTipContent explaining why it's disabled stays reachable. Only the prop type was missing, so TS consumers have to widen the props themselves.

  This came out of elastic/kibana#281982 ([Agent Builder] Return conversation permissions for rename and delete), which disables the Rename / Delete context menu items when the user lacks permission and attaches a toolTipContent explaining why. A natively disabled item is removed from the tab order and dispatches no mouse events, so that explanation is unreachable by both mouse and keyboard — exactly what hasAriaDisabled exists to solve. Because the prop is undeclared, that PR carries two workarounds it can delete once this ships:

  • const AriaDisabledContextMenuItem: React.FC<EuiContextMenuItemProps & EuiDisabledProps> = EuiContextMenuItem; — duplicated in conversation_title.tsx and conversation_list_item_row.tsx.
  • A hand-copied focusEuiToolTipTrigger in the two sibling test files, because the published declarations don't export EUI's own.

• How:

  • EuiContextMenuItemProps now extends Pick<EuiDisabledProps, 'hasAriaDisabled'> rather than the full EuiDisabledProps: the full type also carries isDisabled, and this component's disabled prop is named disabled — extending fully would add a second, dead disabled prop.
  • The prop is destructured and passed to EuiListItemLayout explicitly instead of relying on ...rest, which was accidental and would silently break if rest were ever allow-listed.
  • src/test/rtl/component_helpers.d.ts is hand-written and is the source the build uses for the published lib/test/rtl types (see scripts/compile-eui.js), so focusEuiToolTipTrigger (added in #9201) existed at runtime but not in the published declarations — external consumers got TS2305 importing focusEuiToolTipTrigger from @elastic/eui/lib/test/rtl. Kibana currently inlines a copy of the helper in two test files because of this.

API Changes

component / parent	prop / child	change	description
EuiContextMenuItem	hasAriaDisabled	Added	Beta. Swaps the native disabled attribute for aria-disabled so a disabled item stays focusable and its toolTipContent stays reachable. Runtime behavior was already supported; this only adds the type.
@elastic/eui/lib/test/rtl	focusEuiToolTipTrigger	Added	Missing type declaration for an already-exported test helper

Screenshots

No visual change. The disabled-with-tooltip rendering is unchanged from what EuiListItemLayout already produced for consumers passing the prop through untyped.

Impact Assessment

• 🔴 Breaking changes
• 💅 Visual changes
• 🧪 Test impact
• 🔧 Hard to integrate

Impact level: 🟢 None — purely additive types plus an explicit prop forward; no rendered output changes for existing usages.

Release Readiness

• Documentation: props table is generated from the type, so the beta JSDoc on EuiDisabledProps['hasAriaDisabled'] carries over. The general guidance already lives on the Tooltip / Disabled elements page.
• Figma
• Migration guide
• Adoption plan: elastic/kibana#281982 (agent_builder) is the driving consumer — it deletes the two AriaDisabledContextMenuItem local aliases and the two inlined focusEuiToolTipTrigger copies once this ships.

QA instructions for reviewer

• Open Storybook → Navigation/EuiContextMenu/EuiContextMenuItem → Playground.
• Set disabled: true, hasAriaDisabled: true and fill in toolTipContent.
• Confirm the item renders aria-disabled="true" and no disabled attribute.
• Confirm the tooltip shows on hover and on keyboard focus (Tab to the item).
• Confirm the item does not activate on click or Enter.
• With hasAriaDisabled: false, confirm the item is natively disabled as before.

Checklist before marking Ready for Review

• Filled out all sections above
• QA: keyboard-only verified via unit tests (focus reaches the item, tooltip opens); no visual change to test across themes
• QA: Tested in CodeSandbox and Kibana
• QA: Tested docs changes
• Tests: Added Jest coverage (describe('hasAriaDisabled') in context_menu_item.test.tsx) — verified they fail without the prop forward
• Changelog: Added
• Breaking changes

[brunofarache]

@mgadewoll would you mind taking a look? You worked on hasAriaDisabled in #9214 / #9201, so this is squarely your area — it just adds the missing prop type to EuiContextMenuItem and the missing focusEuiToolTipTrigger declaration.

(I don't have permission to add reviewers on this repo, hence the mention.)

[elastic-vault-github-plugin-prod]

1 visual difference(s) found - expand to review, then click Approve visual changes to update baselines

euidatagrid (1 difference)

Story	Before	After	Diff
compact desktop

[mgadewoll]

🟢 Changes are LGTM. The added behavior works as expected.
Thanks for the update! It's nice to see that hasAriaDisabled is getting more traction beyond the initial set of supported components 🎉

[mgadewoll]

buildkite test this

[infra-vault-gh-plugin-prod]

💚 Build Succeeded

• Buildkite Build
• Commit: f046816

History

• 💚 Build #7284 succeeded f046816

[infra-vault-gh-plugin-prod]

💚 Build Succeeded

• Buildkite Build
• Commit: f046816
• Documentation website
• Storybook
• ✅ Visual regression tests passed

History

• 💔 Build #4540 failed f046816