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

Hm my hunch is the label of the dropdown should be the active item. "Language" in some arbitrary language is not necessarily recognisable by people in other languages.

@shall

Patch#8 looks fine. Lets wait for others to provide their feedback on it.

There is a contrib that does this. https://www.drupal.org/project/dropdown_language

+      setTimeout(
+        function()
+        {
+          menu.classList.add('language-switcher--collapsed');
+        }, 500
+      );

Since this is es6, we should be able to use an arrow function instead. And I think the right function brace would be on the same line, if not using arrow functions

setTimeout(() => menu.classList.add('language-switcher--collapsed'), 500); could work, but it would return something to setTimeout.

+    <div class="language-switcher-toggle" data-drupal-selector="language-switcher-toggle" aria-label="Language Switcher">
+      {% include active_theme_path() ~ '/images/svg/icon-globe.svg' %}
+    </div>

This probably needs role="button" if it's a clickable thing, and check to see if it's tabbable (tabindex=0 may be necessary).

+.language-switcher-toggle {
+  width: 2rem;
+}

This probably needs to set the cursor to a pointer.

I think that's fairly actionable so I'm going to flip to Needs work.

Adding novice tag as well.

I would recommend to use a button element instead of a div with role="button" for a11y. button have already the role="button" per default without applying the role attribute.

Here's an updated version of the patch in #8 that implements a fix to listen for the `transitionend` event, instead of using setTimeout, so that if a user clicks faster than 500ms, we don't apply the collapsed class.

Also refactored to use Drupal.behaviors so the dropdown works well with bigpipe now.

@nullvariable
Just wanted to check if you can generate the interdiff file for the same.

Something's wrong with the patch. I'm not able to apply it with either git apply or patch -p1< either.

It seems that my local settings were a bit fubar, and so the file encoding and line endings were breaking the last patch. Here's a new patch in UTF8 with unix style line endings.

ok, a couple more tweaks after conversing on Slack, and I've also tried to generate an interdiff file. Not sure if I'm doing it right, so feedback or suggestions welcome!

OK :/ Please ignore 19 & 20. 19 contains an issue where the context is too sensitive and causes the behavior not to trigger when you're logged out, and 20 lost the js file entirely for some reason.

This patch should resolve both those issues, and incorporates all of the work up through patch 8.

Regarding #15, there are a ton of styles that would have to be adjusted to switch from a div to a button, so I went ahead and added the role=button attribute to the div. I'm not attached to that, but diving into the stylesheets at that level is a bit outside of my wheelhouse.

I've also removed the "order" rules from the stylesheets per conversation with @shaal

Thanks!

Once more fixed, thanks @shaal for the much better workflow (that actually appears to have worked this time)

Updates look great @shaal

Logged in:

Logged out:

Very clean feel when expanding now.

I added back the Seattle 2019 tag because we shouldn't remove topic or event tags as it helps event organizers to track what issues were worked on.

Review of patch #25:

1. It's not keyboard-operable. A <div role="button"> doesn't have the expected behaviour of a button. The role attribute only addresses semantics, not behaviour. It also needs to be in the keyboard tabbing order, and respond to enter and spacebar keys when focused. The keypress should trigger the same behaviour as a click.

   Recommendation: use a <button type="button">, like @joville already suggested in #15. This will give you all the necessary button behaviour. You just need to provide the click handler, and the browser takes care of the rest. Patch #2 used a real button, but this regressed in patch #4.

   I'm going to assume nobody has actually tried this with a keyboard since patch #3. Please get in the habit of testing things with a keyboard. It takes under a minute and doesn't require assistive technology.

   After changing it to a <button>, make sure it has a focus outline like all our other buttons. We'll hopefully get that for free from existing styles, but remember to check that.

2. diff --git a/core/profiles/demo_umami/themes/umami/templates/components/language-switcher/links--language-block.html.twig b/core/profiles/demo_umami/themes/umami/templates/components/language-switcher/links--language-block.html.twig
   
   +    <div class="language-switcher-toggle" data-drupal-selector="language-switcher-toggle" aria-label="Language Switcher" role="button">

   The aria-label attribute should be translated, so when a viewing a Spanish page, the aria-label will say something like "selector de idioma".

3. diff --git a/core/profiles/demo_umami/themes/umami/images/svg/icon-globe.svg b/core/profiles/demo_umami/themes/umami/images/svg/icon-globe.svg
   
   +<svg data-name="Layer 1" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 567.12 567.12">
   +<title>{{ 'Language'|t }}</title>

   The SVG title element is unnecessary, as the button has an accessible name from the aria-label attribute. The title element can be removed.

4. diff --git a/core/profiles/demo_umami/themes/umami/templates/components/language-switcher/block--languageswitcher.html.twig b/core/profiles/demo_umami/themes/umami/templates/components/language-switcher/block--languageswitcher.html.twig
   
   +<div class="language-switcher-wrapper">
   +  <div class="language-switcher-togglewrap">
   +    <div class="language-switcher-toggle" data-drupal-selector="language-switcher-toggle" aria-label="Language Switcher" role="button">
   +      {% include active_theme_path() ~ '/images/svg/icon-globe.svg' %}
   +    </div>
   +    <div class="language-switcher-arrow">&blacktriangledown;</div>
   +  </div>
   +
   +  <div{{ attributes.addClass(classes) }}>
   

   The resulting <div id="block-languageswitcher" role="navigation"> block wrapper is navigation landmark region. The button should ideally be inside the landmark region, so that a when an assistive tech user jumps to the navigation region, they will find the button inside it. As things stand, the button is outside the landmark region; so when a user arrives at the navigation region it is apparently empty.

   The same mistake was made with the main menu button, and we have #2973258: Place the Umami menu button inside the <nav> element. That issue has been deferred until after the other accessibility issues for the main menu, because it needs a bunch of CSS to be re-worked. We can avoid this situation with the language switcher by getting the markup right first time.

5. diff --git a/core/profiles/demo_umami/themes/umami/js/components/blocks/language-switcher/language-switcher.es6.js b/core/profiles/demo_umami/themes/umami/js/components/blocks/language-switcher/language-switcher.es6.js
   
   +  function init(toggler, menu) {
   
   +    toggler.setAttribute('aria-controls', menu.getAttribute('id')
   

   This results in aria-controls="null", because the ul.language-switcher doesn't have an ID attribute. An ID attribute needs to be generated at some stage (server-side or client-side, it matters not).

6. diff --git a/core/profiles/demo_umami/themes/umami/js/components/blocks/language-switcher/language-switcher.es6.js b/core/profiles/demo_umami/themes/umami/js/components/blocks/language-switcher/language-switcher.es6.js
   
   +  Drupal.behaviors.umamiLanguageSwitcher = {
   
   +        // The template doesn't have the aria expanded attribute, so we can use that as a proxy for first run.
   

   Nitpick - the attribute name should have a hyphen in this comment, i.e. aria-expanded

Re. #21:

Regarding #15, there are a ton of styles that would have to be adjusted to switch from a div to a button, so I went ahead and added the role=button attribute to the div. I'm not attached to that, but diving into the stylesheets at that level is a bit outside of my wheelhouse.

The main navigation menu uses a real <button> when hidden at small breakpoints. Styling is not a reason to avoid using a real button. You can make a similar argument in reverse; using a div instead of a button means a ton of user-agent behaviour has to be re-implemented for keyboard accessibility and assistive technology semantics.

I filed some related accessibility issues about the language switcher in general. These aren't Umami's fault, but if we are adding a custom block template we'll need to follow the same solution as those issues (whichever lands first, don't treat them as blockers for this issue).

Review of patch #29:

1. diff -u b/core/profiles/demo_umami/themes/umami/templates/components/language-switcher/block--languageswitcher.html.twig b/core/profiles/demo_umami/themes/umami/templates/components/language-switcher/block--languageswitcher.html.twig
     
     +      <button class="language-switcher-toggle" data-drupal-selector="language-switcher-toggle" aria-label="{{ 'Language Switcher'|t }}">

   It's best to include an explicit type="button" attribute, because without it the default type is a submit button. This button isn't associated with a form, so the missing type is probably harmless. However it could potentially be announced or classified differently by some assistive tech tech in the future.

2. Recommendation: put the div.language-switcher-arrow inside the <button>. The benefits are:
   • The triangle itself should be part of the clickable area too, I think.
   • When the focus outline goes around both the globe and the triangle, it makes the behaviour clearer; the visible focus operates a drop-down.
3. The focus styles could to with being improved, for the button itself and the nested links. Re-use the styles that the mobile menu uses. Currently the nested links only have top/bottom outlines, and the left/right outlines are missing. Screenshot from Firefox 66:
   
4. The language-switcher--collapsed class isn't being managed correctly. We're relying on this class to provide visibility: hidden to hide it from keyboard and assistive tech users. The class is added in init(), then removed by toggleMenu() and toggleVisiblility(). The class doesn't get added back though, when the menu is collapsed again.
   As things stand, the language switcher passes WCAG 2.4.7 Focus visible when first initialized, but fails that criterion after opening then closing the menu. Steps to reproduce:
   • Load the page, then tab back and forth through controls. There are zero tab stops in between the language drop-down button and the search box. This is OK.
   • Focus the language drop-down button, and press space. The language links are revealed. There are now 2 visible tab stops between the drop-down button and the seach box. This is OK.
   • Focus the language drop-down button again, and press space. The language links are hidden. However there are now 2 invisible tab stops between the drop-down button and the seach box. This is a bug, and fails WCAG Focus Visible.

   To fix this, we need to restore the ul.language-switcher--collapsed class when closing the menu.

5. $:~/web-projects/floss/umami/docroot$ git apply --index ../patches/ootb-language-switcher-dropdown-3042417-29.patch
   ../patches/ootb-language-switcher-dropdown-3042417-29.patch:283: trailing whitespace.
           // The template doesn't have the aria-expanded attribute, so we can use that as a proxy for 
   warning: 1 line adds whitespace errors. 

   Nit-pick: there's a trailing space in this comment.

This is coming along nicely. It would be good to get a test case in place to assert correct aria-expanded state, visiblility (or tab-ability) of links, and response to keypress, similar to what we're doing in the main mobile menu a11y issue.

One more thing I noticed about patch #29:

+ <button class="language-switcher-toggle" data-drupal-selector="language-switcher-toggle" aria-label="{{ 'Language Switcher'|t }}">

The aria-label uses title case here, but sentence case will do for an (invisible) name.

As it happens, this patch introduces "Language Switcher" (title case) as a new string, but there's already a Spanish translation for "Language switcher" (sentence case) from the core language module:

I have reviewed this patch in a call along with @shaal and checked the issues raised for accessibility are addressed. Here's my notes:

#28 @andrewmacpherson’s feedback:

1. Use <button type="button">: This has been done.
2. Translate the aria-label eg: "selector de idioma": This has been done.
3. The svg’s title has been removed.
4. The button should be a child of the role=”navigation” region: It is now an immediate child.
5. aria-controls="null" is now correctly output as aria-controls="language-switcher-languages" along with the appropriate id on the ul.
6. // The template doesn't have the aria-expanded: is now correctly hyphenated

#30 @andrewmacpherson’s feedback:
1. Now has a type=”button”
2. <div class="language-switcher-arrow">▾</div>: Is now nested in the button tag.
3. Focus styles are now following styleguide default.
4. ‘language-switcher-languages--collapsed’: is now being reapplied on closure of the menu

#31 @andrewmacpherson’s feedback:
1. Language switcher is now title case.

I'm setting the patch to RTBC - great work!

Per #32, sounds like @nullvariable needs a credit here.

The accessibility is very nice. All issues from #28, #30, #31 have been addressed. Hawesome!

This should probably have some tests coverage for the behaviour, using WebDriverTestBase or Nightwatch. I'd like to get more keyboard behaviour tests into core; so far we don't have many, and simple components like this are a good place to start. There are some work-in-progress tests at #2940023: [PP-1] Improve accessibility of Umami's responsive main menu which has a very similar circumstances to the language menu here. A good next step would be to look at that, and see if we can get similar tests into both issues.

Have gone through the patch in #43:

1) None of the functions are documented/explained, should they be? Not sure on javascript coding standards, or if it's clear enough on what they do, or because this isn't expected to be used like an API we don't need it.

2)

 // Check context for authenticated users.
+      if (context.classList && context.classList.contains('block-language-blocklanguage-interface') ||
+      // Check context for anonymous users.
+      context.nodeName === '#document') {<code>

Two things here:
a) Can we simplify this if statement by doing something such as the following (this may be redundant based on point b))

var authenticated_user = context.classList && context.classList.contains('block-language-blocklanguage-interface');
if (authenticated_user || context.nodeName === '#document') ...

b) This seems like two very different ways of checking about users... it also seems a little odd we're checking if a user is authenticated or anonymous - that is 100% of users, so seems like that's not what we're actually testing for. What are we actually checking for? Also, do we need this check? Could we not actually remove it, as the next if statement catches us before we try to do anything?

3)

if (menu.length > 0 && toggler && toggler[0].getAttribute('aria-expanded') === null) {
+ 

We probably need to check for menu first too before checking for menu.length, incase no menu is found? That would go well with the suggestion above to remove the first if statement.

4)
+{{ attach_library('umami/language-switcher') }}
This library hasn't been defined, the javascript was added to the global library.

r.e. nightwatch tests: I've made a followup for adding those for both issues/menus, as the plan is to make the code from here more generic & used for both the language & main menu drop down. Do we need to do WebDriver tests for this in the meantime?

Sorry, there was one more thing:

5)

// The template doesn't have the aria-expanded attribute, so we can
+        // use that as a proxy for the first run.

We should be using the jQuery .once included with core if possible for only attaching things once to an element.

Thanks @smaz.

Addressing @smaz's comments in #44 and #45 - possibly still needs work but setting to needs review for the points below:

1. I've skipped this point for now. If it's necessary for commit then more work required.
2. a) and b): Removed the checks for role type as per @smaz's suggestion and the switcher continues to function as expected but agree with @smaz's point, what was the purpose of this code? Overlaps with point 1 and the need for some comments.
3. Add a check for 'menu' into the if statement.
4. I've gone the route of removing {{ attach_library('umami/language-switcher') }} because adding the css and js into a library causes a strange flash of green and height transition to the globe on page load / refresh. This may not be preferable and may require more work to use a library instead.
5. Sorry, I have not worked on the suggestion to use .once because I'm not yet sure how to test what event listeners are firing.

Adding tags.

The patch needs a test written for it still per accessibility review by @andrewmacpherson in comment #36.

@shaal mentioned in Slack asking for some help to convert the global functions using import/export in javascript.

I removed the Needs tests tag based on the previous comment.

This patch looks good.

Manually tested this using mouse and keyboard only. The submenu is not in the tab order when the menu is closed.

Screenshots of before and after with the menu open.
Before:

After:

As there are other issues for improving test coverage and accessibility, I'm marking this as RTBC.

Fix esLint errors for the dropdown, language switcher and mobile main-menu.

Update patch to include @shaal's previous patch

Tested, no console nor linting errors.

@shaal as a maintainer, you can use the "Credit Others" field in the credits section to add those who helped out in the other issue.

Creditting folks who commented on this issue for us, even though they may not have committed a file/code. We like to thank as many people as possible in OOTB

On chrome when I click through the pages there's a flash of the language switcher. That's unexpected to me. Is it meant to happen?

Here's an animated gif that shows #67. The simplest way to trigger it is to press the browser shortcut to reload the page but if can occur when using the menu.

Thanks @shaal this seems like a very clever approach to allow the mobile menu and the language switcher work even with JS turned off or if JS fails to load.

I'm going to mark this as RTBC again. Perhaps in the future we will have an even better solution, but for now I can't think of what that might be. Thanks for all the hard work on this.

1. This issue changes more than just the language switcher so I would probably expand the issue title and issue summary to make it clear that those changes are intentional.

2. +++ b/core/profiles/demo_umami/themes/umami/css/components/blocks/language-switcher/language-switcher.css
   @@ -2,29 +2,92 @@
   +button.language-switcher-toggler {
   ...
   +button.language-switcher-toggler svg {
   
   +++ b/core/profiles/demo_umami/themes/umami/css/components/navigation/menu-main/menu-main.css
   @@ -71,54 +39,100 @@
   +button.menu-main-toggler {
   ...
   +button.menu-main-toggler svg {
   

   Is there a specific reason why these selectors are using button element for targeting the element here?

3. +++ b/core/profiles/demo_umami/themes/umami/css/components/blocks/language-switcher/language-switcher.css
   @@ -2,29 +2,92 @@
   +[aria-expanded="true"] > .language-switcher-arrow {
   

   I don't think we should be using aria-expanded for attaching styles because people changing this wouldn't expect it to affect styling.

4. +++ b/core/profiles/demo_umami/themes/umami/js/components/blocks/language-switcher/language-switcher.es6.js
   @@ -0,0 +1,14 @@
   +import umamiDropdown from '../../dropdown/dropdown.js';
   
   +++ b/core/profiles/demo_umami/themes/umami/js/components/blocks/language-switcher/language-switcher.js
   @@ -0,0 +1,16 @@
   +import umamiDropdown from '../../dropdown/dropdown.js';
   
   +++ b/core/profiles/demo_umami/themes/umami/js/components/navigation/menu-main/menu-main.es6.js
   @@ -3,17 +3,12 @@
   +import umamiDropdown from '../../dropdown/dropdown.js';
   
   +++ b/core/profiles/demo_umami/themes/umami/js/components/navigation/menu-main/menu-main.js
   @@ -5,15 +5,12 @@
   +import umamiDropdown from '../../dropdown/dropdown.js';
   

   This isn't supported by IE 11: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statem... 😓

5. +++ b/core/profiles/demo_umami/themes/umami/templates/components/navigation/menu--main.html.twig
   @@ -44,9 +44,10 @@
   +  {% set component_class = 'menu-main-items' %}
   ...
   +      <ul{{ attributes.setAttribute('id',component_class).setAttribute('data-drupal-selector',component_class).addClass(component_class) }}>
   

   It's a bit strange that the variable name is _class even though it's being set as an ID, data-drupal-selector data attribute and a class. 🤔 Do we really need all of these attributes?

#63: Thank you for helping credit contributors on this issue! Giving credit to contributors is important. It's important for us to recognize various different kinds of contributions, including people who haven't contributed any patches or code. The maintainers have worked on building a consistent system for giving credit across the project. Have you seen the documentation on guidelines who should be credited on Drupal core issues?

Hi @shaal

I'm sorry to report, but this looks broken in IE11. The dropdown for the language switcher works fine, but the height of it is too much making the pre-header region look wrong.

As well as that, the main menu seems to be completely missing in IE11.

Moving this back to Needs Work so we can figure this out - maybe on a joint call some time over the weekend if you (and me) are available.

Here's a screenshot from IE11 (albeit from Browserstack):

Hi @shaal,

#76 patch looks good and now no more issue in IE11.
Attached gif for further reference.

Hence updating status as RTBC.

Sorry to have to pop this back to needs work but the main menu's layout is affected by menu item length. Please see following screenshots.

At install:

With a longer menu item:

We can discuss this in tomorrow's OOTB call because I think this is going to need some design discussion to help resolve.

Thanks @shaal for the updated patch. I've tested this in Firefox and Chrome and it works as per the screenshot you have supplied with the medium breakpoint size reverting the hamburger layout to normal menu as we'd expect.

I think it would be an enhancement to the layout if the following minor tweaks are added to this patch:

.language-switcher-language-url

• Remove 'align-items: center' which will caused the globe to sit left
• Add max-width: 200px; which will prevent the magnifier getting push too far right

.language-switcher-items__item

• Remove text-align: center; to cause language names to align left.

I don't have the option to test in IE11 right now so this still needs to be done.

I performed Novice Triage on this issue. I am leaving the Novice tag on this issue because the patch needs a few more tweaks and then manually tested again in supported browsers, particularly IE11.

I changed the status to Needs work based on @kjay's review in #80.

I am working in this issue

Kindly review patch and i upload a patch as per @kjay suggistions

KIndly review patch.

Something doesn't seem right about the patches uploaded in #83 and #85. It looks like we've reverted the changes in #79. Instead we need to focus on making the only the changes @kjay mentioned in #80 for the selectors mentioned.

Thank you @prabha1997, @neelam_wadhwani for uploading the patches with interdiffs. These are useful, and we can check that the changes between the patches do not correspond to what you may have intended.

I'm unhiding the patch and interdiff in #79 because that has the latest patch to work off.I am leaving the Novice tag on this issue because the next step is still to take apply the fixes from #80 after applying the patch in #79, and then manually test in IE11.

Updated patch #79 as per suggestion in #89
Screenshot after applying #79

Screenshot after applying #90

Verified and tested by applying the patch #90.It looks good to me.Can be moved to RTBC. RTBC +1.
One small observation is there on expanding the dropdown or clicking on it , it gets expand in the upwards direction instead of downwards.The icon should be in downward direction.

Steps to test -
1. Go to the admin site.
2. Go to the home page.
3. Verify the language dropdown UI.

After Patch Mobile View Language dropdown collapse -

After Patch Mobile View Language dropdown expand -

After Patch Desktop View Language dropdown collapse -

After Patch Desktop View Language dropdown expand -

Marking RTBC based on patch from comment #90 - https://www.drupal.org/project/drupal/issues/3042417#comment-13622726 - and review from #94, and manual testing during today's weekly OOTB meeting.

1. +++ b/core/profiles/demo_umami/themes/umami/js/components/dropdown/dropdown.es6.js
   @@ -0,0 +1,109 @@
   +  Drupal.UmamiDropdown = class {
   ...
   +    init(context, element = {}) {
   

   If we have a class, we should have a constructor method, not an init() method we have to call manually afterwards.

2. +++ b/core/profiles/demo_umami/themes/umami/js/components/dropdown/dropdown.es6.js
   @@ -0,0 +1,109 @@
   +    // Private methods for dropdown functionality
   +    static collapseSection(element) {
   ...
   +    static expandSection(element) {
   ...
   +    static toggleMenu() {
   ...
   +    static toggleVisibility(event) {
   

   Static methods are not private, comment is incorrect.

   Why does toggleVisibility has as an argument and toggleMenu doesn't? they are both event listeners.
   I would prefer that we use the data in the event object event.target instead of this to avoid confusions.

3. +++ b/core/profiles/demo_umami/themes/umami/js/components/dropdown/dropdown.es6.js
   @@ -0,0 +1,109 @@
   +        this.classList.add('menu--expanded', 'true');
   ...
   +        this.classList.remove('menu--expanded', 'true');
   

   Do we need to add and remove a 'true' class?

4. +++ b/core/profiles/demo_umami/themes/umami/js/components/dropdown/dropdown.es6.js
   @@ -0,0 +1,109 @@
   +      const toggler = context.querySelectorAll(
   +        `[data-drupal-selector="${element}-toggler"]`,
   +      );
   ...
   +        for (let i = 0; i < toggler.length; i++) {
   +          // Create dropdown only once.
   +          if (!toggler[i].classList.contains('dropdown-initialized')) {
   

   For no-jQuery once we need to work on #2402103: Add once.js to core I'm happy that both umami and olivero don't require jQuery but it's starting to become an issue to replicate D6-era patterns in core.

   Instead of the if we can use :not in the selector. And typically the element selection happens in the behavior, not in the constructor.

The way the class is built and used does not add anything (explicitly passing the element to modify), the same could be done with a simple object and an initialization function.

I am triaging this issue for Global2020. I left the Needs manual testing tag because we'll still need to redo that after the changes in #98.

Patch updated to include comment #98 fixes

can you post an interdiff as well please? it's a big patch so interdiff helps https://www.drupal.org/documentation/git/interdiff

The init function was replaced but the usage in language switcher was not updated. The libraries declaration for the dropdown library is also missing. Did you test the patch? would be safer to use the patch from #90 to address the feedback

The jQuery once issue is close, so I'd like to hold off on commit so that we can use the vanilla-js once method.

I am removing the Novice tag from this issue because the issue is effectively postponed on #2402103: Add once.js to core.

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

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

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

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 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.

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

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.