Add Collapsed Status for Menu Block Title

We need to get the design mocks for this one from Figma.

Gonna try it

Postponed because this functionality is already partially done here https://www.drupal.org/project/navigation/issues/3427659 📌 Implement drawer functionality Needs review

This has bee implemented in 📌 Implement drawer functionality Needs review and 📌 Implement the new designs to the drawer Needs review . But one small detail is missing: the pointer style should be defined so the browser doesn't show a "?".

Added styles based on the final designs, plus updated the issue summary to reflect the final designs and testing steps.

One problem to note, if you try to tab through the collapsed sidebar, menu block titles are not focusable. with tabbing that structuring element is unavailable to screenreader users. the only cue screenreader users have is that there are four headers by default (in case the display of title is active):

shortcuts
content
administration
rkoller

just based on the announcement it is not clear that those are actual section headers, you would need the visual context. in addition tabbing is the only way to get all the menu block titles as well as menu items in consecutive order. in the voice over rotor the components are scattered, the block titles are headers, top level items with a sub menu are buttons and top level items without a submenu are links.

@rkoller thanks for the feedback! Could you open a follow-up issue for that and add it into the accessibility plan? It's not that I don't care about accessibility, but we need to move and iterate fast to get the navigation to a better point, and the classic core treatment of issues where nothing gets in until it's perfect will slow us down in this very key moment. :)

@rkoller opened 📌 Improve how and what navigation block titles are communicating to screenreader users Active as a follow-up for the keyboard issue.

There are only two concerns i have. For the first i've already opened up a follow up issue in the context of keyboard and screenreader accessibility (will add another comment about the needs for sighted keyboard users there as well).
the other detail is about the dot, but that concern shouldnt be a blocker for this issue. overall it is difficult to communicate with just an icon that the user should hover over the icon (when i first saw the dot i thought some icon was missing - like for a missing unicode glyph) . creating another follow up issue wouldnt make much sense since that issue wouldnt be actionable and with the navigation issue queue moving over into the core issue cue soon it would be cruft for the time being. @ckrina made a note about the dot and will continue ideating on it over with the folks in the design team. therefore no followup issue necessary in this case. therefore this issue could be set to rtbc

Thanks @rkoller! Merging this for now and we can make the improvements in a follow-up.

Automatically closed - issue fixed for 2 weeks with no activity.