Olivero primary search button should be initialized with aria-expanded="false" by JS

On fresh page load, aria-expanded="false" added by patch #3.

Adding after-patch screenshot for reference.

Patch #3 works good. Added a screen recording to show the toggle.

+++ b/core/themes/olivero/js/search.es6.js
@@ -77,4 +77,24 @@
+      if (searchWideButton)

According to Drupal coding standards, control structures should always use curly braces around them https://www.drupal.org/docs/develop/standards/javascript/javascript-codi...

Patch #8 looks good to me, confirming RTBC.

I love the test coverage here. (I've read it, but I haven't run it...)

Some nitpicks, but no more work needed...

1. Updating issue title. It's really about initializing the button state, rather than anything to do with an icon. We'd need this whether the button contained text or an icon.
2. The movie in #5 doesn't actually show a page load taking place. I'll trust that recording started just after a fresh page load, but it doesn't rule out the possibility that the movie was recorded after opening/closing the search box once.
3. This issue isn't minor. It wasn't accurately conveying the state (or behaviour) of an interactive control, which comes under WCAG SC 4.1.2 Name, Role, Value. That's a level-A criterion, for which we use major. This should be added as a must-have to the Olivero roadmap.

For triage, I think it's unlikely that any issue involving dynamic ARIA states will ever warrant being demoted to minor.

Great work everyone, and nice bug-catch!

Hang on, I have a question.

I see that...

• This is specifically about initializing the search button at wide viewport widths.
• Attaching the behaviour makes use of once()

If the page is loaded with a narrow viewport, and then the user changes the CSS viewport width afterwards (e.g. by increasing window size, or reducing browser zoom level), will the search-wide button still have the aria-expanded=false correctly initialized?

Thanks for the demo in #11, that's great.

Meanwhile, another little nitpick with the button. The accessible name is a bit poor: aria-label="Toggle Search Form".

There's no need for the word "Toggle" here, because...

1. It isn't needed to convey the open/close behaviour. The mere presence of an aria-expanded attribute (whether true or false) is sufficient to convey the behaviour. A screen reader will say "button, collapsed" or "button, expanded" which conveys that it is expand/collapse-ible.
2. "Toggle" can actually be misleading, because "Toggle button" is how some screen readers (in the English locale, at least) announce <button aria-pressed="true|false">. Using "toggle" as part of the name for a disclosure button may be sending mixed message about how it behaves. I think we covered this already? Perhaps it was in an issue about the sub-navigation buttons.

Let's improve it here, under the overall scope of WCAG "Name, role, value".

TODO: Remove the word "toggle" from the aria-label - aria-label="Search Form". Then screen readers will typically say "Search Form, button, collapsed". A user will expect a search form to be revealed by pressing the button.

The narrow-viewport main menu button also has an unnecessary "toggle" in the name. I'll file a separate issue about that now.

Forgot to update status for #12

Hmm, okay. I think WCAG Name, Role, Value was a pretty well contained scope here; not really scope creep.

Anywayhowsomedivver.... recap:

• I agreed with RTBC in #9
• My question from #10 was answered in #11, not a problem
• #12 is deferred to a trivial issue

So back to RTBC.

Committed c96121d and pushed to 9.3.x. Thanks!