[EuiHeader] Increase z-index value

[acstll]

Summary

Resolves #8206

Note

Please refer to the original issue in order to better understand the problem

To summarize the problem: in a Project View in Kibana (e.g. Serverless) when a Flyout is open, the navigation in Collapsible Nav Beta is reachable via keyboard, even though it stands behind the Flyout's overlay (screenshot).

We have evaluated more than one way to solve the issue. Most of them have problems. The one presented here feels like the least fragile (it won't shouldn't create other problems down the road) and the least complex.

Instead of excluding the navigation from the focusable elements in the Header (e.g. adding the inert attribute to it while the Flyout is open) —as suggested in the original issue—, this PR goes a different way: it brings the navigation up above, on top of the Flyout's overlay, so it's OK for it to be focusable.

It's also worth mentioning that this is the way the Classic view works: if you toggle the navigation open with a Flyout open, it goes on top of the overlay and it's reachable.

The z-index of the Header has been changed from 1000 to 2000. But it remains below everything else (e.g. modals) it was below before. The relationship between the Header's z-index and other components whose z-index is relative to it, remains the same. Only the z-index relationship between Header and Flyout is changed.

Only the z-index of the fixed Header has been increased by 1, leaving everything else unaffected.

Here's a recording demoing the idea

Screen.Recording.2025-02-12.at.22.43.59.z-index.mov

The one remarkable side-effect, and at first glance the only, of the change is the Header's shadow appearing over the Flyout (screenshot below).

Shadow appearing:

Before (current)	After (with the fix)

---

QA

https://eui.elastic.co/pr_8325/#/layout/header/elastic-pattern-project

Important

The example header_elastic_pattern_project.tsx is there only for testing purposes, not meant to be merged!

To test this locally

• checkout PR locally (e.g. gh pr checkout 8325)
• run yarn start in packages/eui
• visit http://localhost:8030/#/layout/header/elastic-pattern-project
• open Alerts flyout on the top right corner

General checklist

• Browser QA
  • Checked in both light and dark modes
  • Checked in mobile
  • Checked in Chrome, Safari, Edge, and Firefox
  • Checked for accessibility including keyboard-only and screenreader modes
• Docs site QA
  • Added documentation
  • Props have proper autodocs (using @default if default values are missing) and playground toggles
  • Checked Code Sandbox works for any docs examples
• Code quality checklist
  • Added or updated jest and cypress tests
  • Updated visual regression tests
• Release checklist
  • A changelog entry exists and is marked appropriately.
  • If applicable, added the breaking change issue label (and filled out the breaking change checklist)
• Designer checklist
  • If applicable, file an issue to update EUI's Figma library with any corresponding UI changes. (This is an internal repo, if you are external to Elastic, ask a maintainer to submit this request)

[acstll]

I think the fix is solid now. I want to add a test.

[mgadewoll]

The one remarkable side-effect, and at first glance the only, of the change is the Header's shadow appearing over the Flyout

@acstll I think this is a drawback we have to accept but I'd suggest to get an approval of design on this too.

[acstll]

@acstll I think this is a drawback we have to accept but I'd suggest to get an approval of design on this too.

Definitely, I'm requesting a review from Ryan 🙏 (@ryankeairns I remember you mentioned a suggestion regarding the shadow…?)

[acstll]

@ryankeairns I'll request a review again in a bit when this is ready-ready 😁

[acstll]

@mgadewoll I think I addressed all pending changes 🤓

• updated changelog 192efcc
• improved flyout story to include focusable items cf1f070
• checked mobile behaviour 7686c05
• test collapsible nav in flyout shards cdebce0

[mgadewoll]

🚢 🐈‍⬛ Thanks for digging into this! The solution is technically definitely the best value for impact. Let's wait for design thoughts from @ryankeairns before merging though.

[ryankeairns]

It's hard to argue with the accessibility gain. Visually, I believe it is a bit of a downgrade but not enough to stop from proceeding. As a mitigating effort, let's decrease the size of the shadow on the header.

Changing this line to euiShadowXSmall

https://github.com/elastic/eui/blob/887efb88c88bc930a7348af2f4c84ed4c7502b32/packages/eui/src/components/header/header.styles.ts#L41C9-L41C23

...which results in...

[mgadewoll]

It's hard to argue with the accessibility gain. Visually, I believe it is a bit of a downgrade but not enough to stop from proceeding. As a mitigating effort, let's decrease the size of the shadow on the header.

Changing this line to euiShadowXSmall

https://github.com/elastic/eui/blob/887efb88c88bc930a7348af2f4c84ed4c7502b32/packages/eui/src/components/header/header.styles.ts#L41C9-L41C23

@ryankeairns To confirm: we're fine changing it generally for EuiHeader, correct? Or should it be for fixed headers only?

And an additional side thought: We'll change the shadows for Borealis soon (issue) which will remove euiShadowXSmall - will the new euiShadowSmall work fine then anyway?

[kibanamachine]

Preview staging links for this PR:

• Docs site: https://eui.elastic.co/pr_8325/
• Storybook: https://eui.elastic.co/pr_8325/storybook
• New docs: https://eui.elastic.co/pr_8325/new-docs

[elasticmachine]

💚 Build Succeeded

• Buildkite Build
• Commit: 0123868

History

• 💚 Build #3549 succeeded 59bdf51
• 💚 Build #3494 succeeded bb61e92
• 💔 Build #3493 failed 1c98683
• 💚 Build #3491 succeeded 108ab90
• 💚 Build #3489 succeeded 192efcc
• 💚 Build #3478 succeeded 49c1ae5

cc @acstll

[ryankeairns]

It's hard to argue with the accessibility gain. Visually, I believe it is a bit of a downgrade but not enough to stop from proceeding. As a mitigating effort, let's decrease the size of the shadow on the header.
Changing this line to euiShadowXSmall
https://github.com/elastic/eui/blob/887efb88c88bc930a7348af2f4c84ed4c7502b32/packages/eui/src/components/header/header.styles.ts#L41C9-L41C23

@ryankeairns To confirm: we're fine changing it generally for EuiHeader, correct? Or should it be for fixed headers only?

Yes. (Do we differentiate the style per position today?)

And an additional side thought: We'll change the shadows for Borealis soon (issue) which will remove euiShadowXSmall - will the new euiShadowSmall work fine then anyway?

🤔 Are we removing XSmall or flat? I thought it was the latter... in any case, I still feel this change - on this PR - is helpful for the interim/Amsterdam.

[mgadewoll]

@ryankeairns Thanks for the confirmation!

Yes. (Do we differentiate the style per position today?)

No, we don't. If we could distinguish fixed headers while a flyout is open, that might be an idea for adjusting it conditionally, but currently that's not a thing.

🤔 Are we removing XSmall or flat? I thought it was the latter... in any case, I still feel this change - on this PR - is helpful for the interim/Amsterdam.

I thought both, but looking at the specs here again it does define xs still so ... maybe? 😅 🤷‍♀️

[mgadewoll]

@acstll I already added the change and will go ahead and merge your PR. 🚀