Should tooltip trigger on activedescendant "focus" or should I implement this manually?

[SantoJambit]

The Tooltip component shows if the trigger element gets focus or if someone hovers it, but there is another case where it's kind of a focus:

In Autocomplete, Combobox or Tags Input, you have an input element, which receives the main focus, but other elements like the options in the dropdown or tag "buttons" can be selected via arrow keys.

The browser or screen reader can be told about this via the aria-activedescendant attribute. So it's kind of a secondary focus.

Now to my question: If an option (in the combobox or the tag button gets "secondary-focused" via aria-activedescendant, should it trigger the Tooltip component if it is wrapped in one? Or should I manually implement this behavior with a controlled open state?

Also feel free to comment on the pros and cons for the UX of having a Tooltip in these places.

[TargiX]

I would not make TooltipTrigger automatically treat aria-activedescendant as DOM focus.

aria-activedescendant intentionally keeps DOM focus on the composite widget (for example, the combobox input) while telling assistive technology which option is currently active. The referenced option does not receive a native focus/blur event. The WAI-ARIA combobox pattern describes exactly this distinction: https://www.w3.org/WAI/ARIA/apg/patterns/combobox/

The tooltip pattern, on the other hand, is triggered by actual keyboard focus or pointer hover on its trigger: https://www.w3.org/WAI/ARIA/apg/patterns/tooltip/

Automatically combining those two concepts inside Tooltip would be surprising because:

• a single focused input can move aria-activedescendant through many options;
• there is no native focus event on those options;
• it could make tooltips appear during ordinary arrow-key navigation even when the consumer does not want them.

For supplemental visual help, I would control the tooltip manually from the combobox/tag input's highlighted or active value. For information required to understand an option, I would keep it in the option's accessible name/description instead of relying on a tooltip.

So my recommendation is: keep the current Tooltip focus semantics, and implement this as controlled behavior at the composite-widget level when a product explicitly wants it.