Unfortunately this is not correct for all languages

On a multilingual page with language switch enabled, the language names shown in the list or specified in the alt attribute of the flag icons are written in a particular language (English language name in English, Polish language name in Polish, German language name in German), and so on.

See the following list taken from the joomla.org/4 site

aria-label="English (United Kingdom)
alt="English (United Kingdom)"
aria-label="Czech (Čeština)"
alt="Czech (Čeština)"
aria-label="Welsh (United Kingdom)"
alt="Welsh (United Kingdom)"
aria-label="Danish (Danmark)"
alt="Danish (Danmark)"
aria-label="Deutsch (Deutschland)"
alt="Deutsch (Deutschland)"
aria-label="Greek (el-GR)"
alt="Greek (el-GR)"
aria-label="English (Australia)"
alt="English (Australia)"
aria-label="English (United States)"
alt="English (United States)"
aria-label="Español (España)"
alt="Español (España)"
aria-label="French (France)"
alt="French (France)"
aria-label="Italiano (it-IT)"
alt="Italiano (it-IT)"
aria-label="日本語 (Japan)"
alt="日本語 (Japan)"
aria-label="Nederlands nl-NL"
alt="Nederlands nl-NL"
aria-label="Português (Portugal)"
alt="Português (Portugal)"
aria-label="Português do Brasil (pt-BR)"
alt="Português do Brasil (pt-BR)"
aria-label="Русский (Россия)"
alt="Русский (Россия)"
aria-label="Slovak (Slovakia)"
alt="Slovak (Slovakia)"
aria-label="Slovenščina (Slovenija)"
alt="Slovenščina (Slovenija)"
aria-label="Swedish (Sweden)"
alt="Swedish (Sweden)"
aria-label="Thai (ภาษาไทย)"
alt="Thai (ภาษาไทย)"
aria-label="Turkish (Turkey)"
alt="Turkish (Turkey)"

@brianteeman Thx.
Perhaps I did not express myself clearly. Let me try another way.
When a blind person, selects his language in the language switcher, for example, he expects to hear its name in his language in the screen reader.
To meet this expectation, the name of the target language should always be given in that language and should be programmatically tagged with the appropriate value of the lang attribute. Otherwise, a well-configured screen reader will not apply the correct pronunciation rules.
Therefore, in my opinion, we should improve the module's code to declare the language of the part (language names) and - possibly - in the author's guidelines emphasize that the names of the target languages should be written in the target language.
The language switch is quite critical for language accessibility.
For example, on a page in Polish, the screen reader will not correctly read the word "Chinese" written in Chinese, because most likely it will not recognize that this name is written in Chinese.

As far as I can see, the language switcher uses the native_title of the content language. If that is correctly set to a value in the particular language, the proposed solution would work, but as soon as people edit the content language and set the native_title to something else, it will not fit anymore.

@richard67 : Language switcher uses the page default language.
When Ukrainian is among the languages to choose from on my site, the screen reader should read me its name in Ukrainian, because that is how it is written ("Yкраїнська"). But since its default language is the language of the site, not the language of the content section, it only reads me phonetically the first Cyrillic character, which it recognizes as "Y." It does not read the name of the language to me. If I am a blind Ukrainian, such a language switcher is useless to me.

I understood you perfectly. I was just pointing out that your statement about the languages that I quoted was not 100% correct and provided a list of examples to provide evidence that it was not correct

@richard67 : Language switcher uses the page default language. When Ukrainian is among the languages to choose from on my site, the screen reader should read me its name in Ukrainian, because that is how it is written ("Yкраїнська"). But since its default language is the language of the site, not the language of the content section, it only reads me phonetically the first Cyrillic character, which it recognizes as "Y." It does not read the name of the language to me. If I am a blind Ukrainian, such a language switcher is useless to me.

I was referring to what is written, not to in which language the screenreader reads it. What is written is determined by the native_title of the content language.

@richard67
Yes, The language name, as indicated, is (should be) specified in the target language (Native Title). E.g. "English" for English, "Русский" for Russian, "Español" for Spanish etc.
In order for web browsers and assistive technologies to render this name correctly, according to the spelling and pronunciation rules of the language, they must have information in the lang attribute about what language this name is written in. Otherwise, they attempt to render it according to the rules of the page's default language.
Currently, the tag, which includes the language name given in the alt attribute of the flag icon, in the aria-label attribute and in the link text, does not have the lang attribute, which indicates in which language this name is written

@zwiastunsw There is no need to explain the same thing again and again. We are not stupid.

Maybe I'm misunderstanding. But I read your statements to mean that there is no accessibility issue here. If we agree that there is an accessibility problem, then - of course - my clarification is not needed. :)

There are TWO options here and there is much debate online as to which is correct for this case (personally I go with 2 which is what I think you go with)

1. The strngs are presented in the language of the site at that time
2. The strings are presented in the language of the language being selected

BUT
For both option 1 and option 2 the problem as I displayed above is that we do not have the strings available.

Yes, it’s a problem that the initial texts come from the language packs, and translators don’t handle the native title right. Furthermore, a user can change the native title in the options of the content language to anything they want, and that can be in any language. So when we blindly set a lang property, it might be wrong in the one or the other case. A way out could be a new option in the content language to add a lang property, but that could also be confusing the user.

Can someone add a feature tag to this please