[feat] Secondary nav initial render improvement

[zhawkins]

Description

We've got light DOM CSS that ships along with secondary nav (Yay!) but the "open by default on mobile" state we chose is a performance regression (Boo!).

https://www.webpagetest.org/video/compare.php?tests=230601_BiDcB8_9SQ,230504_BiDcC9_CX7

Suggested solution

I believe the problem is there's not a great no-or-broken-js way to collapse the menu by default but allow it to be accessible.

I've pulled together an example of how we might be able to accomplish this with the target selector:

https://codepen.io/zackhawkins/full/BaqXwBz

@hellogreg threw together a better/different option with the following demo using a checkbox approach:

This isn't perfect, but it works pretty well with mouse, keyboard, and/or screen reader. I built upon a Heydon Pickering version of the checkbox hack--which suits nav menus better than some other cases where I've seen it. Gave the checkbox a button role and used aria-live to announce visually-hidden expanded and collapsed text (as opposed to a JS-toggled aria-expanded attribute) to screen readers. Currently set up so the expanded menu list pushes down other content, though absolute positioning could make it overlap, if you want.

Demo: https://cdpn.io/pen/debug/BaqXwwR
Code: https://codepen.io/hellogreg/pen/BaqXwwR?editors=1100

Example API

No response

Additional context

No response

[bennypowers]

is noscript a target here? do you have usage stats that we can reference to determine how much of our audience is noscript? can we solve this in part or in whole by defaulting to closed menu and adding dsd for fouc?

[zhawkins]

noscript is not a target. This is about initial render (having the nav in a collapsed state by default) and because it's in a collapsed state by default, providing a fallback to allow the user to open the nav if JavaScript fails to load or something breaks.

[zeroedin]

After discussion with @hellogreg we talked through current possible noscript fixes and each just present a different accessibility tradeoff to users. The future goal would be DSD providing a <details> element as the closed mobile menu that would load closed and provide users access sans javascript. Noted there are also still safari shortcomings around details current announce open/close state.

[hellogreg]

Yeah, <details> currently doesn't play well with the Mobile Safari / VoiceOver combo (though is fine with Mac Safari / VoiceOver). It announces neither a default role nor (as @zeroedin said) expanded/collapsed state. Putting an explicit "button" role on <summary> will announce the role in iOS, but it then also stops announcing expanded/collapsed state in Mac Safari!

I know from my own experience and from some articles that VoiceOver used to announce state with older versions of iOS (e.g., 11 and 12). But for some reason it does not announce state with recent versions. (iOS has never announced default roles for <details>, as far as I know.)

Sample <details> element with no CSS, JS, or explicit roles.

[zhawkins]

I'm not opposed to that, but mind you that Safari is a good chunk of our mobile traffic on RHDC. After all, this is the "everything has gone wrong" fallback.

Currently all mobile users on slower connection speeds or lower powered devices (and a lot of our mobile traffic is Chrome) see the menu open by default and then shuffle close.

[markcaron]

Moving to a Discussion, since we don't have a specific, proper solution that is both accessible and without CLS—as is the nature of all properly accessible hamburger menus.

Currently documenting potential approaches.