Don't make the header sticky by default

[afercia]

Description

it's a known fact that fixed / sticky headers or top bars may introduce usability and accessibility issues. While testing the footnotes block in the context of WordPress/gutenberg#54843 I noticed that the sticky header in the theme makes the user experience less than ideal.

Specifically, following a footnote link and clicking the 'jump back' link in the footnote does make the page scroll as expected but the page frgment that should scroll into view is always hidden behind the fixed header.

This is a very confusing experience for all users (it happens also when clicknw with mouse) and even more confusing for keyboard users.

Since the sticky header height can't be predicted, as it actually depends on the amount of links in the navigation, the only option I can think of is to change the default setting. The header should not be sticky by default. That would provide users with a default user experience that is less than ideal.

Step-by-step reproduction instructions

Expected behavior

Focused links and controls to be visible.

Screenshots

Animated GIF to illustrate the footnotes behavior:

Environment info

Additional context

[afercia]

One more good reason to not have the header (technically it's the header group container) sticky by default is when the navigation contains many links,

In this scenario, most of the page content may be hidden behing th efixed header. Not sure the default setting should be so limiting. Instead, the default should be a sensible default that covers most of the cases. If users want a sticky header, they can change the setting at any time to fit their specific needs. The default should work best for all scenarios.

Screenshot with navigation containing meny links:

[afercia]

The above is even more important considering the inability to change the 'sticky' setting globally.

When users want to change this setting, they have to do it manually for each template. I'd argue this is a very frustrating experience and I'm not sure it helps users in any way. Cc @carolinan

[richtabor]

Screenshot with navigation containing meny links:

I don't disagree with potentially changing the header to not be sticky, though this screenshot is far from the likely result. We should strive to resolve towards likely/expected results, rather than extreme.

[luminuu]

I wonder why it was decided to make the header sticky in the first place. I think the footnotes example is a much bigger issue than the massive menu one. As we should strive to make an accessible-ready theme, I'd be in favour of removing the stickiness from the header.

[beafialho]

I don't disagree with potentially changing the header to not be sticky, though this screenshot is far from the likely result. We should strive to resolve towards likely/expected results, rather than extreme.

+1000

[afercia]

I think the footnotes example is a much bigger issue than the massive menu one.

I agree. The 'massive' menu example is obviously an edge case. I'd like to point out that also a smaller menu that goes in two or three rows on mobile would be problematic though.

[sabernhardt]

Skip to content links can have a similar problem too.

The example of a giant menu, or multiple shorter rows on a smaller screen, illustrates that the header does not have a predictable height (or even an expected height range). I have used scroll-padding-top to compensate for a fixed header, though it probably is not a practical option in this case.

[carolinan]

There is also a problem with the sticky menu and the lightbox focus outline. When the lightbox is "closed", the focus outline of the image is above the sticky header, but visually the image is below. I would like to look at this closer before I create a GitHub issue though.

[kafleg]

I'm also in favor of not having a sticky header.

[afercia]

Just a note that a few days ago October 5) the Web Content Accessibility Guidelines 2.2 became the new official recommendation. The new recommendation introduces some new success criteria. One of them is relevant:

Success Criterion 2.4.11 Focus Not Obscured (Minimum)
(Level AA) [New]
https://www.w3.org/TR/WCAG22/#focus-not-obscured-minimum

When a user interface component receives keyboard focus, the component is not entirely hidden due to author-created content.

In a few words, this new success criterium requires to ensure that, when an item gets keyboard focus, it is at least partially visible.

That means that, from now on, for Core and bundled themes any fixed / sticky / absolutely positioned element and the like must not hide the currently focused element, for example when tabbing forwards and backwards. Any fixed / sticky header and the like are basically banned unless there is a mechanism in place to make sure the focused element is always (at least partially) visible.

See a brief description on the 'What's new' post at:
https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/#2411-focus-not-obscured-minimum-aa

[luminuu]

Thanks for sharing this detailed information @afercia! Since the sticky header got removed, we're good to go. :)

[afercia]

Since the sticky header got removed, we're good to go. :)

Thanks @luminuu I know the default setting is not sticky now, thanks. My point is that all bundled theme and also Core should remove any such fixed sticky elements unless there is a mechanism to make the focused element always visible.

This applies not only to Twenty Twenty-Four but also to all the previous and future bundled themes, if they sue such positioning:

• The old themes should be audited to be compliant.
• Future themes should be designed form scratch to be compliant.

I thought this was an important information for the Themes team.

[luminuu]

@afercia This is indeed important, but since we're only working on Twenty Twenty-Four here, I think it would be the best if you open an issue in Trac and label it with bundled-themes. Otherwise, this information will just get lost here, as the repo is only worked with until 6.4, after that it gets archived.