E-mail List Archives
Thread: Screen reader testing on language switching components.
Number of posts in this thread: 10 (In chronological order)
From: BrianD
Date: Mon, Apr 28 2025 8:36AM
Subject: Screen reader testing on language switching components.
No previous message | Next message →
Hi to all.
I'm interested in hearing from anyone on this list, who has tested language switcher components using a screen reader.
What methodology do you use to carry out your testing? Do you simply check that when the desired language is chosen, that the screen reader will switch into the selected language? Or do you test that the various elements on a page, such as links and buttons get announced in the desire language too.
Thanks in advance.
Best wishes,
Brian Dalton.
From: Steve Green
Date: Mon, Apr 28 2025 9:55AM
Subject: Re: Screen reader testing on language switching components.
← Previous message | Next message →
It depends on what the objective of the test is. When testing for WCAG conformance, there is no need to use a screen reader at all. You just look at the "lang" attributes in the switcher and in the resulting pages. You need to check for "lang" attributes throughout the pages, not just in the html element.
If you want to go beyond a WCAG audit and test the user experience, things get really messy because the screen reader behaviour will depend on the synthesizer(s) that are installed. Each synthesizer only supports a selection of languages, maybe only one language. Screen readers can be set to switch between languages automatically, but this only works if both languages use synthesizers from the same vendor.
If you have synthesizers from different vendors, you need to switch language manually. Depending on what the languages are, it may not be possible to get all the synthesizers from the same vendor.
If you have checked that all the "lang" attributes are correct, you only need to do a minimal amount of screen reader testing - I typically only test a few words. To check the "lang" attributes, I usually search the DOM and use some custom CSS with the Stylus browser extension to visually show where the "lang" attributes are on a page. There are probably other tools and bookmarklets that do the same.
Steve Green
Managing Director
Test Partners Ltd
From: Dean.Vasile---
Date: Mon, Apr 28 2025 10:14AM
Subject: Re: Screen reader testing on language switching components.
← Previous message | Next message →
Recently, I was testing a website.
And it had two different language selectors one was a language translation and the JAWS behavior even with auto forms mode turned off. Focus would automatically pop into this window, and when I was navigating by form element inadvertently typed the letter F and the language automatically changed to French.
I then had to locate the field again activated intentionally press the letter, E and then select English.
Then there was another language selector when signing up for this app where the user was required to select the language for emails.
This action opened a very complex model window that did not give the screen reader user notifications, nor was it easily navigable using normal table commands.
Looking at the Dom as Steve recommends, will not actually be able to give you the information that the screen reader user was experiencing . the elements in this modal also appeared as Text. They were not coded as links or buttons.
Dean Vasile
IAAP, CPACC
= EMAIL ADDRESS REMOVED =
617-799-1162
> On Apr 28, 2025, at 11:55 AM, Steve Green via WebAIM-Forum < = EMAIL ADDRESS REMOVED = > wrote:
>
> It depends on what the objective of the test is. When testing for WCAG conformance, there is no need to use a screen reader at all. You just look at the "lang" attributes in the switcher and in the resulting pages. You need to check for "lang" attributes throughout the pages, not just in the html element.
>
> If you want to go beyond a WCAG audit and test the user experience, things get really messy because the screen reader behaviour will depend on the synthesizer(s) that are installed. Each synthesizer only supports a selection of languages, maybe only one language. Screen readers can be set to switch between languages automatically, but this only works if both languages use synthesizers from the same vendor.
>
> If you have synthesizers from different vendors, you need to switch language manually. Depending on what the languages are, it may not be possible to get all the synthesizers from the same vendor.
>
> If you have checked that all the "lang" attributes are correct, you only need to do a minimal amount of screen reader testing - I typically only test a few words. To check the "lang" attributes, I usually search the DOM and use some custom CSS with the Stylus browser extension to visually show where the "lang" attributes are on a page. There are probably other tools and bookmarklets that do the same.
>
> Steve Green
> Managing Director
> Test Partners Ltd
>
>
From: Mark Magennis
Date: Mon, Apr 28 2025 10:25AM
Subject: Re: Screen reader testing on language switching components.
← Previous message | Next message →
Hi Brian,
The last time I looked at language switchers (maybe three years ago) it was difficult to code a language menu that worked well with all screen readers and worked equally well when you changed the screen reader’s language. This was due to variable support for the lang attribute, particularly within an ARIA menuitem. It turned out to be less problematic to avoid using an ARIA menu. But if using a menu, I found after a lot of experimentation that the best pattern was to:
1. Display language options using the character set and spelling of their language.
2. Add the lang attribute to each menuitem, set to the appropriate value for the language (except for the currently selected language where it is best to leave out the lang attribute).
3. Add an aria-label to each menuitem, containing the language name as it is spelled in the current UI language.
4. Add the suffix “, current language” to the aria-label of the option that was shown as selected (had a tick mark).
This resulted in options being repeated twice by some screen readers and in some slightly unclear choices like “Castilian Spanish Mexican Spanish” but it seemed to offer the best overall results where at least every option was read and in a language that is understandable to the user. But best to avoid using an ARIA menu like I said.
Mark
Mark Magennis
Principal Product Manager, Accessibility
[Skillsoft]<http://www.skillsoft.com/>;
From: Steve Green
Date: Mon, Apr 28 2025 10:28AM
Subject: Re: Screen reader testing on language switching components.
← Previous message | Next message →
I was only addressing the handling of different languages. You obviously need to test all the other relevant WCAG success criteria. But even then, it is rarely necessary to use a screen reader because you can predict the behaviour if you can understand the code. And anyone doing a WCAG audit needs to be able to understand the code.
I am not opposed to testing with a screen reader, but only after inspecting the code. Screen readers all behave differently, and their behaviour is also affected by their settings and the choice of synthesizer. It's not very helpful to report issues in terms of screen reader behaviour unless you can also specify what is wrong with the code.
Steve
From: Steve Green
Date: Mon, Apr 28 2025 10:37AM
Subject: Re: Screen reader testing on language switching components.
← Previous message | Next message →
Why would you add the "aria-label" attributes at step 3? If I understand what you are saying, if the current page is in English, the link to the German version would have the visible text "Deutsch" but it would have the attributes aria-label="German" and lang="de". If that's what you mean, it would fail SC 2.5.3 (Label In Name) and a screen reader would say "German" in a German accent.
Steve
From: BrianD
Date: Mon, Apr 28 2025 3:33PM
Subject: Re: Screen reader testing on language switching components.
← Previous message | Next message →
Hi Steve and Mark.
Many thanks for your responses.
Steve, your comments about the synthesiser behaviour make perfect sense.
Personally as a screen reader user, I'm not fond of the automatic switching of languages, I would prefer to control that manually with a language switcher, and I agree with you re the checks for the lang attributes on each page.
Mark, thanks for your observations too. I will bear those in mind when I'm testing, and offering solutions.
Best wishes,
Brian Dalton.
From: Mark Magennis
Date: Thu, May 01 2025 3:38AM
Subject: Re: Screen reader testing on language switching components.
← Previous message | Next message →
It sounds like you're right Steve. It would fail 2.5.3. As for how it would pronounce the label, that may also be an issue and whilst my memory of testing this with screen readers is weak I concluded at the time that this was the best of a bad bunch of options and I will always opt for practical usability rather than WCAG compliance. Having said that, I think I only tested in English, German and French because the product didn't support other languages so it may be less robust with other languages.
Mark
From: Steve Green
Sent: Monday, April 28, 2025 17:37
To: WebAIM Discussion List
Cc: Mark Magennis
Subject: RE: [WebAIM] [EXTERNAL] Screen reader testing on language switching components.
Why would you add the "aria-label" attributes at step 3? If I understand what you are saying, if the current page is in English, the link to the German version would have the visible text "Deutsch" but it would have the attributes aria-label="German" and lang="de". If that's what you mean, it would fail SC 2.5.3 (Label In Name) and a screen reader would say "German" in a German accent.
Steve
From: Steve Green
Date: Thu, May 01 2025 3:49AM
Subject: Re: Screen reader testing on language switching components.
← Previous message | Next message →
In my view, each link in the language switcher should be written in the language that the link points to, and it should have the corresponding "lang" attribute. It doesn't matter that a person who speaks the language that is currently selected cannot understand some of the links. The important thing is that someone who needs to switch to another language can find the appropriate link.
Steve
From: Mark Magennis < = EMAIL ADDRESS REMOVED = >
Sent: 01 May 2025 10:38
To: Steve Green < = EMAIL ADDRESS REMOVED = >; WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXTERNAL] Screen reader testing on language switching components.
It sounds like you're right Steve. It would fail 2.5.3. As for how it would pronounce the label, that may also be an issue and whilst my memory of testing this with screen readers is weak I concluded at the time that this was the best of a bad bunch of options and I will always opt for practical usability rather than WCAG compliance. Having said that, I think I only tested in English, German and French because the product didn't support other languages so it may be less robust with other languages.
Mark
From: Steve Green
Sent: Monday, April 28, 2025 17:37
To: WebAIM Discussion List
Cc: Mark Magennis
Subject: RE: [WebAIM] [EXTERNAL] Screen reader testing on language switching components.
Why would you add the "aria-label" attributes at step 3? If I understand what you are saying, if the current page is in English, the link to the German version would have the visible text "Deutsch" but it would have the attributes aria-label="German" and lang="de". If that's what you mean, it would fail SC 2.5.3 (Label In Name) and a screen reader would say "German" in a German accent.
Steve
From: Kevin Prince
Date: Thu, May 01 2025 8:37PM
Subject: Re: Screen reader testing on language switching components.
← Previous message | No next message
Agreed - and that goes for languages that don't use the same character set as English - Cyrillic, kanji etxc. Don't forget you also need to add a right to left attribute for Arabic etc
Kevin