E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 10 (In chronological order)

From: glen walker
Date: Thu, Dec 17 2020 10:35AM
Subject: can you make a native <select>/<option> honor the LANG attribute?
No previous message | Next message →

I love to demo how JAWS will switch voices/accents when it encounters
language changes on a webpage. (I have not been able to get NVDA to do
that, even when I have different languages installed.)

When there's a feature to change the language, and the feature is a custom
element, it's easy to put the LANG attribute on the different language
elements. But if we want to honor semantic html and encourage the first
rule of ARIA use and recommend the use of a native <select> over a custom
combo, how do you get the language honored?

For example, if you go to the UPS home page,
https://www.ups.com/us/en/global.page (if you've been to UPS before and
already selected a language, you'll have to bring up a private or incognito
browser window to get the language selection again), there are options to
choose your location. The list of languages has the LANG attribute on the
<li> elements. JAWS switches accents just fine.

But if you go to Thoughtexchange,
https://my.thoughtexchange.com/scroll/693698427, they have a native
<select> for the languages. I tried putting the LANG attribute on the
<option> elements (via the code inspector) but it didn't cause JAWS to
change languages. (On other pages where I add LANG dynamically via the
code inspector, it works, so this isn't an issue with JAWS not updating its
buffer or anything. I also tried adding LANG before starting JAWS.)

LANG is a global attribute (
https://www.w3.org/TR/html53/dom.html#global-attributes-2) so technically
can be used on any element and in theory should work on <option>.

Perhaps this is a bug in the browser not surfacing the language to
assistive tech. I tried it on Firefox, Chrome, and Safari. VoiceOver is
similar to JAWS in that it'll switch voices based on the language. The UPS
page works with Mac/VoiceOver but a <select>/<option> with the LANG
attribute does not.

Is this a case where we would recommend a custom element instead of a
native one?

From: Birkir R. Gunnarsson
Date: Thu, Dec 17 2020 1:13PM
Subject: Re: can you make a native <select>/<option> honor the LANG attribute?
← Previous message | Next message →

Yeah, this is a tricky one.
So, ideally, (and not everything is ideal), changing the langauge
should be a click action, as opposed to a select/focus action.
If possible, I'd code it as a series of links (if it loads a different
page) or toggle buttons (if the content on the page is updated).
Activating the button would update the langauge of the page.
I know the lang attribute works on a link, I'd have to test if it
works on a button.
So, if you have control and if you don't have hundreds of languages,
I'd use links or buttons for language change, not a dropdown.
For the rest, well, I think you'd have to use a custom dropdown and
see if that works. If the native one cannot update the language, it'd
be a good enough reason for creating a custom one.
I'm also curious what the behavior is like for radiobuttons.



On 12/17/20, glen walker < = EMAIL ADDRESS REMOVED = > wrote:
> I love to demo how JAWS will switch voices/accents when it encounters
> language changes on a webpage. (I have not been able to get NVDA to do
> that, even when I have different languages installed.)
>
> When there's a feature to change the language, and the feature is a custom
> element, it's easy to put the LANG attribute on the different language
> elements. But if we want to honor semantic html and encourage the first
> rule of ARIA use and recommend the use of a native <select> over a custom
> combo, how do you get the language honored?
>
> For example, if you go to the UPS home page,
> https://www.ups.com/us/en/global.page (if you've been to UPS before and
> already selected a language, you'll have to bring up a private or incognito
> browser window to get the language selection again), there are options to
> choose your location. The list of languages has the LANG attribute on the
> <li> elements. JAWS switches accents just fine.
>
> But if you go to Thoughtexchange,
> https://my.thoughtexchange.com/scroll/693698427, they have a native
> <select> for the languages. I tried putting the LANG attribute on the
> <option> elements (via the code inspector) but it didn't cause JAWS to
> change languages. (On other pages where I add LANG dynamically via the
> code inspector, it works, so this isn't an issue with JAWS not updating its
> buffer or anything. I also tried adding LANG before starting JAWS.)
>
> LANG is a global attribute (
> https://www.w3.org/TR/html53/dom.html#global-attributes-2) so technically
> can be used on any element and in theory should work on <option>.
>
> Perhaps this is a bug in the browser not surfacing the language to
> assistive tech. I tried it on Firefox, Chrome, and Safari. VoiceOver is
> similar to JAWS in that it'll switch voices based on the language. The UPS
> page works with Mac/VoiceOver but a <select>/<option> with the LANG
> attribute does not.
>
> Is this a case where we would recommend a custom element instead of a
> native one?
> > > > >


--
Work hard. Have fun. Make history.

From: Steve Green
Date: Thu, Dec 17 2020 2:04PM
Subject: Re: can you make a native <select>/<option> honor the LANG attribute?
← Previous message | Next message →

There is another curious twist. If you put a "lang" attribute on the <select> element, JAWS ignores it if you press the spacebar to open the list of options and arrow through them. However, if you go into forms mode and arrow through the options while the list is closed, JAWS does honour the "lang" attribute.

Steve Green
Managing Director
Test Partners Ltd

From: glen walker
Date: Thu, Dec 17 2020 2:09PM
Subject: Re: can you make a native <select>/<option> honor the LANG attribute?
← Previous message | Next message →

Thanks, Steve, but doesn't each item in the dropdown list need its own
language since each represents a different language? It sounds like you
put LANG on the <select> itself, which can only have one language and is
the container for all the language choices. It's interesting that arrowing
up/down through the list when its collapsed will honor the language but
that would just be for the LANG on the <select>, right? Or did you put the
LANG on all the <option> elements? (I could probably just try it instead
of asking :-)).

On Thu, Dec 17, 2020 at 2:04 PM Steve Green < = EMAIL ADDRESS REMOVED = >
wrote:

> There is another curious twist. If you put a "lang" attribute on the
> <select> element, JAWS ignores it if you press the spacebar to open the
> list of options and arrow through them. However, if you go into forms mode
> and arrow through the options while the list is closed, JAWS does honour
> the "lang" attribute.
>
>

From: Steve Green
Date: Thu, Dec 17 2020 2:22PM
Subject: Re: can you make a native <select>/<option> honor the LANG attribute?
← Previous message | Next message →

Yes, I know that what I did wouldn't address your issue, but there will be other use cases where a "lang" attribute would be appropriate on the <select> element. I didn't put "lang" attributes on the <option> elements because we had already determined that this has no effect.

Steve

From: Jared Smith
Date: Thu, Dec 17 2020 2:52PM
Subject: Re: [EXT] can you make a native <select>/<option> honor the LANG attribute?
← Previous message | Next message →

I can confirm the same behavior on VoiceOver with Chrome and Safari, and VoiceOver mobile. VoiceOver does not change language when exploring the options, even if the proper <option lang> value is defined. It reads them all in English.

Interestingly, VoiceOver mobile does (sometimes) properly read non-Latin words in their proper language, but this is because it's guessing based on the script of the characters, not because the lang attribute is being considered.

We just today wrapped up some fairly extensive screen reader testing of lang attribute support and found this inconsistency to be fairly standard. Several screen readers do not support inline language changes ("language of parts") for inline elements (<span>, etc.), but does for block-level elements (<p>, <div>, etc.). It seems <option> aligns with the former. A list of links, or perhaps a custom menu (such as on UPS) is probably a better alternative until these deficiencies are addressed.

WebAIM will very soon be publishing a new article with guidance on using lang. I'll share our test cases and testing results at that time.

Thanks,

Jared

From: Birkir R. Gunnarsson
Date: Thu, Dec 17 2020 3:04PM
Subject: Re: [EXT] can you make a native <select>/<option> honor the LANG attribute?
← Previous message | Next message →

Ooh! I'm looking forward to that blog post!
Honestly, as a screen reader user (as opposed to an expert) I prefer
to hear the page with the same synth and turn of language detection on
demand. Heck, I'm even more comfortable reading Icelandic with an
English TTS engine by now, which is odd seeing as I actually helped
create the Icelandic TTS engine.

I find it really difficult to navigate multi-lingual pages where the
screen reader is constantly switching between TTS engines. With
English I have at least a vauge idea of what the words are. I'd be
curious to hear what other screen readerusers prefer.


On 12/17/20, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> I can confirm the same behavior on VoiceOver with Chrome and Safari, and
> VoiceOver mobile. VoiceOver does not change language when exploring the
> options, even if the proper <option lang> value is defined. It reads them
> all in English.
>
> Interestingly, VoiceOver mobile does (sometimes) properly read non-Latin
> words in their proper language, but this is because it's guessing based on
> the script of the characters, not because the lang attribute is being
> considered.
>
> We just today wrapped up some fairly extensive screen reader testing of lang
> attribute support and found this inconsistency to be fairly standard.
> Several screen readers do not support inline language changes ("language of
> parts") for inline elements (<span>, etc.), but does for block-level
> elements (<p>, <div>, etc.). It seems <option> aligns with the former. A
> list of links, or perhaps a custom menu (such as on UPS) is probably a
> better alternative until these deficiencies are addressed.
>
> WebAIM will very soon be publishing a new article with guidance on using
> lang. I'll share our test cases and testing results at that time.
>
> Thanks,
>
> Jared
>
>
> > > > >


--
Work hard. Have fun. Make history.

From: Michael Ausbun
Date: Thu, Dec 17 2020 3:35PM
Subject: Re: [EXT] can you make a native <select>/<option> honor the LANG attribute?
← Previous message | Next message →

--_005_DM6PR02MB5034F59492E8F04D5496E9B992C40DM6PR02MB5034namp_
Content-Type: text/plain; charset=WINDOWS-1252
Content-Transfer-Encoding: quoted-printable

To be honest, I feel the same way. I've trained my brain to process certain=
pronunciations and other eccentricities at a specific speed, with a specif=
ic TTS engine. When small changes occur, productivity is drastically reduce=
d. Even very minor adjustments can result in processing issues for me.
Respectfully,
Michael


--
Michael Duane Ausbun, MA, CPWA (He, His, Him)
Accessibility Specialist, Program Development,
Universal Design and Accessibility Team
Ruston, Louisiana

Western Governors University
4001 South 700 East, Suite 700
Salt Lake City, UT 84107
= EMAIL ADDRESS REMOVED =


[IAAP CPWA small circular badge and horizontal name logo for International =
Association of Accessibility Professionals (IAAP) Certified Professional in=
Web Accessibility (CPWA) credential. To the left is a dark blue circle wit=
h three lines of centered white text that read: IAAP Certified CPWA. There =
is a smaller silver circle that surrounds the dark blue inner circle that d=
esignates the CPWA credential color scheme. To the right, three lines of da=
rk blue text. Top text reads Certified Professional, second line reads in W=
eb Accessibility, third line reads International Association of Accessibili=
ty Professionals.]<https://www.accessibilityassociation.org/cpwa>

[JAWS Certified, 2020]<http://www.freedomscientific.com/Certification>;



From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Birk=
ir R. Gunnarsson
Sent: Thursday, December 17, 2020 4:05 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] [EXT] can you make a native <select>/<option> honor t=
he LANG attribute?

[EXTERNAL EMAIL] WARNING: This email originated from outside of Western Gov=
ernors University.

Ooh! I'm looking forward to that blog post!
Honestly, as a screen reader user (as opposed to an expert) I prefer
to hear the page with the same synth and turn of language detection on
demand. Heck, I'm even more comfortable reading Icelandic with an
English TTS engine by now, which is odd seeing as I actually helped
create the Icelandic TTS engine.

I find it really difficult to navigate multi-lingual pages where the
screen reader is constantly switching between TTS engines. With
English I have at least a vauge idea of what the words are. I'd be
curious to hear what other screen readerusers prefer.


On 12/17/20, Jared Smith < = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >> wrote:
> I can confirm the same behavior on VoiceOver with Chrome and Safari, and
> VoiceOver mobile. VoiceOver does not change language when exploring the
> options, even if the proper <option lang> value is defined. It reads them
> all in English.
>
> Interestingly, VoiceOver mobile does (sometimes) properly read non-Latin
> words in their proper language, but this is because it's guessing based o=
n
> the script of the characters, not because the lang attribute is being
> considered.
>
> We just today wrapped up some fairly extensive screen reader testing of l=
ang
> attribute support and found this inconsistency to be fairly standard.
> Several screen readers do not support inline language changes ("language =
of
> parts") for inline elements (<span>, etc.), but does for block-level
> elements (<p>, <div>, etc.). It seems <option> aligns with the former. A
> list of links, or perhaps a custom menu (such as on UPS) is probably a
> better alternative until these deficiencies are addressed.
>
> WebAIM will very soon be publishing a new article with guidance on using
> lang. I'll share our test cases and testing results at that time.
>
> Thanks,
>
> Jared
>
>
> > baim.org>
> discussion/archives>
> @list.webaim.org>
>


--
Work hard. Have fun. Make history.
im.org/>
scussion/archives>
ist.webaim.org>

--_005_DM6PR02MB5034F59492E8F04D5496E9B992C40DM6PR02MB5034namp_
Content-Type: image/png; name="image001.png"
Content-Description: image001.png
Content-Disposition: inline; filename="image001.png"; size=212;
creation-date="Thu, 17 Dec 2020 22:35:45 GMT";
modification-date="Thu, 17 Dec 2020 22:35:45 GMT"
Content-ID: < = EMAIL ADDRESS REMOVED = 2FEE70>
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAbAAAABRCAMAAACE/wOLAAAAAXNSR0ICQMB9xQAAAANQTFRFAAAA
p3o92gAAAAF0Uk5TAEDm2GYAAAAJcEhZcwAAEnQAABJ0Ad5mH3gAAAAZdEVYdFNvZnR3YXJlAE1p
Y3Jvc29mdCBPZmZpY2V/7TVxAAAAOElEQVR42u3BAQEAAACCIP+vbkhAAQAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAHcGiQEAAVO2oVUAAAAASUVORK5CYII=
--_005_DM6PR02MB5034F59492E8F04D5496E9B992C40DM6PR02MB5034namp_
Content-Type: image/png; name="image002.png"
Content-Description: image002.png
Content-Disposition: inline; filename="image002.png"; size=190;
creation-date="Thu, 17 Dec 2020 22:35:45 GMT";
modification-date="Thu, 17 Dec 2020 22:35:45 GMT"
Content-ID: < = EMAIL ADDRESS REMOVED = 2FEE70>
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAAGwAAABsCAMAAAC4uKf/AAAAAXNSR0ICQMB9xQAAAANQTFRFAAAA
p3o92gAAAAF0Uk5TAEDm2GYAAAAJcEhZcwAAEnQAABJ0Ad5mH3gAAAAZdEVYdFNvZnR3YXJlAE1p
Y3Jvc29mdCBPZmZpY2V/7TVxAAAAIklEQVRo3u3BMQEAAADCoPVPbQ0PoAAAAAAAAAAAAAAAeDct
/AABKxOv+wAAAABJRU5ErkJggg==
--_005_DM6PR02MB5034F59492E8F04D5496E9B992C40DM6PR02MB5034namp_--

From: Jared Smith
Date: Thu, Dec 17 2020 3:40PM
Subject: Re: [EXT] can you make a native <select>/<option> honor the LANG attribute?
← Previous message | Next message →

> Ooh! I'm looking forward to that blog post!

Stay tuned!

> Honestly, as a screen reader user (as opposed to an expert) I prefer
> to hear the page with the same synth and turn of language detection on
> demand.

Our testing found that many screen readers will not switch to sub-variants of a language when the default language matches the content's primary language. As an example, if your default screen reader voice is Great Britain English, that is the voice used for all English pages, even if the content is defined with lang="en-US". This makes sense, I think, one would generally prefer and have better success hearing the English content in their preferred dialect as opposed to the one specific by the page author. This is especially true for dialects like Cantonese and Mandarin that are not usually mutually intelligible.

Your scenario of having Icelandic content read in English is also the default in most screen readers if the Icelandic voice is not installed or enabled. This works because they are both Latin-based scripts. Of course this would not work for non-Latin languages (such as Russian or Japanese) when the default screen reader language is a Latin script. However, in this case, most screen readers do indicate the language of the content even if it cannot read it (at least presuming the correct lang attribute value is specified).

Of course these are the ideal behaviors - there are plenty of bugs and inconsistencies in screen readers when it comes to language support.

Jared

From: wolfgang.berndorfer
Date: Fri, Dec 18 2020 9:27AM
Subject: Re: [EXT] can you make a native <select>/<option> honor the LANG attribute?
← Previous message | No next message

A language change of synth within a page is really quite disrupting for me
too. But hearing a wrong pronunciation trains my brain to speak in wrong
pronunciation, as I personally experienced. It's good to have SR settings to
decide between plague and cholera.