Language Switcher not Accessible (Lighthouse going from 100% to 84% as soon as Module is published)

[woluweb]

Steps to reproduce the issue

On a J4.1 website, publish a Language Switcher.

Expected result

Lighthouse > accessibility was 100% and should stay 100%.

Actual result

Lighthouse > accessibility goes down to 84%

See detail & screenshot hereafter:

• ARIA
  • Elements with an ARIA [role] that require children to contain a specific [role] are missing some or all of those required children.
  • [role]s are not contained by their required parent element
• TABLES AND LISTS
  • List items (
  • ) are not contained within
    or
    parent elements.

  

  Additional comments

  I first shared this information in the A11Y group on Glip / Ring Central where @chmst proposed me to open the issue here. I share hereafter the first analysis by @drmenzelit:

  One problem with the language switcher is that the ul is defined as role="listbox" but the role="option" is not in the li element, but in the a element inside the li... Another problem is the listbox has more than one tabbable element... it seems that in a list the user should be able to navigate between the elements with other key then Tab

  "The primary keyboard navigation convention uses Tab and Shift+Tab
   key commands to move focus from one UI component to another. Other keys
   (primarily the arrow keys) move focus within components comprised of 
  multiple focusable elements. Authors must follow this convention and 
  provide no more than one tab stop per component (providing keyboard 
  focus)."

  If I'm not wrong, we used this: https://w3c.github.io/aria-practices/examples/listbox/listbox-collapsible.html as guide for the dropdown variant of the language switcher, and that seems to be deprecated now...

[simbus82]

I can confirm the Lighthouse problem with Joomla 4.1.2. But, about the "Tables and lists" problem (missing UL or OL), i think it's a detection problem. I see this code generated in my 4.1.2 website with the standard mod_languages:

<div class="mod-languages">
  <ul class="lang-inline">
    <li dir="ltr">
      <a href="#it">IT</a>
    </li>
    <li class="lang-active" dir="ltr">
      <a href="#en">EN</a>
    </li>
  </ul>
</div>

[woluweb]

I forgot to mention explicitely:

1. I am using Cassiopeia
2. the generated HTML is the following

<div class="mod-languages">
    <p class="visually-hidden" id="language_picker_des_195">
        Sélectionnez votre langue
    </p>

    <ul role="listbox" aria-labelledby="language_picker_des_195" class="mod-languages__list lang-inline">
        <li class="lang-active">
            <a aria-current="true" role="option" aria-label="Français (FR)" href="https://www.mydomainname.com/fr/">
                FR
            </a>
        </li>
        <li>
            <a role="option" aria-label="English (UK)" href="/en/"> EN </a>
        </li>
        <li>
            <a role="option" aria-label="Nederlands" href="/nl/"> NL </a>
        </li>
    </ul>
</div>

[dgrammatiko]

Remove the role="option" A link should not change it's role (unless someone is doing it on purpose. Also it should be wrapped in a nav element as it is essential navigation and last the role="listbox" is also wrong

[drmenzelit]

What about this solution: https://russmaxdesign.github.io/language-switcher/

[brianteeman]

And how would that work if you have 4 or more languages

[drmenzelit]

I don't understand the question... We have 2 options now: dropdown or horizontal list. I'm talking of replacing the horizontal list with the radio buttons. It is semantically correct and the user can navigate through the option with the arrow keys, what is correct. Making keyboard navigation inside the list is much more complicated: https://w3c.github.io/aria-practices/#kbd_general_within

But it is only a suggestion I found as reading more about this topic.

[brianteeman]

@dgrammatiko is correct about the role being incorrect. please test #37483

[simbus82]

I don't understand the question... We have 2 options now: dropdown or horizontal list. I'm talking of replacing the horizontal list with the radio buttons. It is semantically correct and the user can navigate through the option with the arrow keys.

Just to clarify in case anyone thinks about these things ...This is really wrong for a website frontend. The "language" switcher must renders links with a real URL that can be indexable by search engine, or will break the whole multilanguage SEO, bacause you loose destination urls to the other languages. A "language switch" is not a UI interaction like in an APP or in "admin backend", but it's a navigation to a new url. Google says "Consider adding hyperlinks to other language versions of a page" in the SEO guidelines. (in fact we no longer use language dropdown on SEO and UX driven websites, it is an anachronistic thing)

The current markup is fine - just the additional roles that were added that is wrong. #37483 corrects that

[drmenzelit]

@simbus82 thank you for the explanation, you are right, I didn't take the links in account... doing too much things at the same time is not a good idea ;-)

[drmenzelit]

Closing as we have a PR #37483