[EuiToolTip] [A11y] Tooltip content not announced in Chrome when rendered inside EuiFlyout

[seialkali]

Reported by

@seialkali

Describe the bug
Tooltips (EuiToolTip / EuiIconTip) rendered inside a EuiFlyout are not always announced by screen readers in Chrome, even though tooltips outside of a flyout behave as expected.

This issue appears to be specific to tooltips rendered inside a flyout that traps focus. The same tooltip component, when placed directly on the page or inside a type="push" flyout, is announced correctly. However, it is still not guaranteed to work inside a type="push" flyout, as you can see in the codesandbox below.

Impact and severity

End-user impact: Yes.
Severity: Moderate accessibility issue.

Screen reader users in Chrome are unable to access tooltip content when the tooltip trigger is inside a non-push flyout. This can result in missing explanatory or critical contextual information.

Tooltips are commonly used to explain form fields, icons, and actions. If the tooltip content is not announced, users may be blocked from understanding the UI.

Environment and versions

• EUI version: Latest
• Browser: Chrome
• Operating System: macOS
• Assistive Technology: VoiceOver

Minimum reproducible sandbox

https://codesandbox.io/p/sandbox/pedantic-rain-yhkv4f?file=%2Fdemo.tsx

To Reproduce

1. Open the sandbox link above in Chrome on macOS
2. Enable VoiceOver
3. Press the button in the demo to open the EuiFlyout
4. Navigate to a tooltip trigger inside the flyout
5. Attempt to read or interact with the tooltip content

Current VoiceOver announcement:

The result when you press the keyboard command for to interact with the content:

Expected behavior
When the tooltip trigger receives focus, VoiceOver should allow the user the hear the tooltip content, either directly or via keyboard command.

Additional context (Optional)

• Chrome: tooltip content inside non-push flyouts is ignored
• Safari + VoiceOver: tooltip content is announced as expected
• Tooltip behavior is correct when not inside a flyout

[acstll]

I can confirm the issue, I was able to reproduce it as described.

However, for the "Chrome + VoiceOver" combination, the suggestion I get from VoiceOver for an interaction command is VO-Command-Slash and not VO-Shift-Down Arrow. With the Slash command I do get the tooltip text in an separate window (couldn't make a screenshot). (I wonder what VoiceUser users use in this kind of scenario, I'm not familiar with these interaction commands at all.)

Tooltips are commonly used to explain form fields, icons, and actions. If the tooltip content is not announced, users may be blocked from understanding the UI.

I'm not completely certain but I think it's not a good practice to rely on tooltips for any critical information that may block the user.

In summary, as already shared in the issue above, the "Safari + VoiceOver" combination works as expected (what we use as a reference for testing). In "Chrome + VoiceOver" is still possible to get the info with the VO-Command-Slash command.

[seialkali]

Hi @acstll, thanks for looking into this. Could you confirm if this is something you're planning to fix? I wasn't sure from your summary, as you said you were able to replicate the issue, but then that you were able to get the info with the VO-Command-Slash command. As it stands, I'm not receiving the VO-Command-Slash command as option in "Chrome + VoiceOver" for tooltips in flyouts, so I am unable to get more info.

Just wondering if I should close the original a11y issue as a tooltip bug we're unable to fix, or if this is something that will be fixed eventually and I should keep the issue in our backlog. Thanks!

[acstll]

hey @seialkali, np!

Could you confirm if this is something you're planning to fix?

we will know later today as we discuss it in our planning sync… — in my comment above I wanted to validate the issue and add some thoughts to help with triaging.

My apologies for not being more clear on the next steps 🙏

I'm not receiving the VO-Command-Slash command as option in "Chrome + VoiceOver" for tooltips in flyouts, so I am unable to get more info.

this is interesting, I wonder why that is… what version of macOS are you running? me it's v26.2

[seialkali]

@acstll Thanks for the clarification! I'm also on Mac v26.2. Would I be helpful if I sent a screen recording of what I'm seeing?

[acstll]

@acstll Thanks for the clarification! I'm also on Mac v26.2. Would I be helpful if I sent a screen recording of what I'm seeing?

that should help, if you're so kind 🙏

I should close the original a11y issue as a tooltip bug we're unable to fix, or if this is something that will be fixed eventually and I should keep the issue in our backlog.

the latter 👍

I've moved this into the backlog. It's high in our list of a11y issues. We'll get to it, I just cannot say exactly when.

---

I was under the wrong impression "Chrome + VoiceOver" was less important in terms of prioritization. Do you know if we have any documentation on that regard?

[seialkali]

@acstll I don't know of any documentation for prioritizing screen reader/browser combinations, but if I find anything I will send it your way!

Here's a screen recording I took of the me opening the flyout in the sandbox included in the issue and tabbing to the tooltip in the header. You can see the command in VoiceOver instructs me to use the command Control-Option-Shift-Down Arrow to interact with the image, and when I do that, VoiceOver says that the content is empty.

Let me know if I can help in any other way!

Screen.Recording.2026-02-05.at.14.25.06.mov

[tutelaris]

Hey @acstll , any updates on prioritizing this issue?

[weronikaolejniczak]

@tutelaris we have a Tooltip sweep coming up, we could potentially pull it in. @alexmarhaba

This issue seems related to #9283 (if not exactly the same)

[weronikaolejniczak]

Hoping this gets fixed by removing the delay from the tooltip: #9552

If you have any other cases, please let me know 🙏🏻