Accessible dropdown for Umami's language-switcher and mobile main-menu

Hi, I was contacted through the #recipes on slack to see if I can fix this. I'm mostly front end but have taken Mike Anello's Professional Module Development class Spring 2024 and was web developer at Kaspersky Lab North America on Drupal 6 subscriptions, OEM, and new product downloads with message screens. Built this higher education and state government website - we're a Massachusetts state college https://www.massbay.edu front and back end Drupal 7. Built Drupal 10 directory https://live-directory2024.pantheonsite.io/massbay-directory?page=20.

We're workiing with Boston Digital a Drupal Service Provider to schlep the maiin website into Drupal 10. I'm checking out W3C WAI etc., sounds like it has the pause but you don't want the pause, having two buttons to toggle click may be the way. Perhaps not just on the language dropdown but all the others.

Will DL Drupal 11 dev branch with git/compser and Umami install and work with it in docker, ddev, phpstorm, phpstan, xdebug, phpcs.

School has Accessibility coaches/lab that can maybe test with real clients,

Wendy Walsh -- Drupal since 2008

markconroy → changed the visibility of the branch 3042417-accessible-dropdown-for to hidden.

markconroy → changed the visibility of the branch 3042417-testing-ignore-this-branch to hidden.

Here's a new rewrite of adding an accessible dropdown for the language switcher, which I think is a lot simpler than what we have been trying up to now. Given that no one has worked on this in over 4 years, I think a re-write is warranted, so we can stop the discussion about things not working in IE11, and compiling our ES6 code to ... etc.

Here's my approach:

• Create a template for the language switcher block
• Put a button in that block with the hidden attribute on it, so it's not visible on the page
• Use JS to remove that hidden attribute so we can see the button
• Use JS to add a hidden attribute to the languages so they are now invisible
• Add an eventListener for a click on the button, if clicked toggle its aria-expanded attribute between true/false, then toggle the hidden attribute on the languages correspondingly
• Add a resize function to check the window width
• When the window is resized, if it's below768px do the above items, if not, reset everything
• Update the CSS so we have the following screenshorts - small screen closed languages, small screen open languages, large screen languages

---
Thanks to Code Enigma for sponsoring my time to work on this.

most generally, We should account for more space then just 2 active languages. As often sites can have 4-7. this would make the desktop design (to show as inline items) not as 'ready out of the box' considering the 'head width' available.

-Put a button in that block with the hidden attribute on it, so it's not visible on the page
-Use JS to remove that hidden attribute so we can see the button
-Use JS to add a hidden attribute to the languages so they are now invisible

A. are you concerned with JS degrade, or just the breakpoint hide/showing.
B. a reminder of projects like https://www.drupal.org/project/dropdown_language → (which i maintain) to remind that Unami Profile can provide a block plugin that is the block to be placed with whatever Accessible Ready UI (button and links) with the true language paths and SEO readhy hreflang's.

We should account for more space then just 2 active languages. As often sites can have 4-7

I was thinking that as well, though in this specific instance we know we only have 2. But, good point. I'll make a small change tomorrow to give us the exact same experience on mobile and desktop, with all the languages in a vertical list. That will actually be less code and more scalable.

Are you concerned with JS degrade, or just the breakpoint hide/showing.

I have tested this with JS turned off, and it works fine. This is just to make sure that we don't see the button if JS doesn't load, but we do see the links.

Think additional resource have to be up the OpenTelemtry tests?

Also do we need test coverage or we good since its a demo profile?

@smustgrave can you rephrase this please? I'm not sure I follow what you mean.

Think additional resource have to be up the OpenTelemtry tests?

The test failures in OpenTelemetryAuthenticatedPerformanceTest

Hi, I will do this.