WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

#28858 closed defect (bug) (fixed)

New installation: Language Selector

Reported by: joedolson Owned by:
Milestone: 4.0 Priority: normal
Severity: normal Version: 4.0
Component: Upgrade/Install Keywords: dev-feedback
Focuses: accessibility Cc:

Description (last modified by ocean90)

1) Button to move forward has no text. There needs to be some kind of text in the step button for screen reader users to know what's happening. Patch adds text 'Set'.

2) Focus is being manipulated so that radio buttons can only be navigated when fieldset is focused, but the fieldset can't receive focus from the keyboard. Patch adds tabindex='-1' so that the fieldset can receive focus.

3) Languages are written in native language, but have no lang attribute to inform screen reader how to pronounce the language. Patch adds lang="$language['language']" -- this will not be complete, because the WP language profiles do not match the ISO 639 language code list http://www.loc.gov/standards/iso639-2/php/code_list.php. Might be a good idea to set up a language reference so that these can be mapped appropriately.

4) For sighted keyboard users, navigating the language list does not trigger scrolling in the language container. This means that any user who can't use a mouse to navigate the list will not be able to select their language if it's outside the default visible options. Needs: trigger scrolling one keypress. And I'm not sure how to do that.

Attachments (1)

28858.patch (1.7 KB) - added by joedolson 3 years ago.
Improves a11y of language selector

Download all attachments as: .zip

Change History (16)

@joedolson
3 years ago

Improves a11y of language selector

#1 @ocean90
3 years ago

  • Description modified (diff)

#2 @SergeyBiryukov
3 years ago

  • Milestone changed from Awaiting Review to 4.0

#3 in reply to: ↑ description @johnbillion
3 years ago

Replying to joedolson:

3) Languages are written in native language, but have no lang attribute to inform screen reader how to pronounce the language. Patch adds lang="$language['language']" -- this will not be complete, because the WP language profiles do not match the ISO 639 language code list http://www.loc.gov/standards/iso639-2/php/code_list.php. Might be a good idea to set up a language reference so that these can be mapped appropriately.

The Translations API now includes ISO 639 codes for each language, so we can use the ISO 639-1 code in the lang attribute which is what RFC 1766 recommends.

#4 @johnbillion
3 years ago

In 29260:

Add a lang attribute to each language listed on the language selector screen during installation. See #28858, #28577.

#5 @joedolson
3 years ago

That's awesome; I didn't know those codes were available. Thanks!

#6 follow-up: @nacin
3 years ago

Not all languages have an ISO 639-1 code.

#7 in reply to: ↑ description @johnbillion
3 years ago

Replying to joedolson:

2) Focus is being manipulated so that radio buttons can only be navigated when fieldset is focused, but the fieldset can't receive focus from the keyboard. Patch adds tabindex='-1' so that the fieldset can receive focus.

4) For sighted keyboard users, navigating the language list does not trigger scrolling in the language container. This means that any user who can't use a mouse to navigate the list will not be able to select their language if it's outside the default visible options. Needs: trigger scrolling one keypress. And I'm not sure how to do that.

After some discussion, we might well switch back to a regular select element to avoid these issues. See my latest patch on #28577. It'd be good to get a11y feedback on it too.

#8 @joedolson
3 years ago

From an accessibility standpoint, I'm 100% in favor of moving to a standard implementation of a select element; it adds a level of predictability that will make the feature much easier to manage, although it does mean that we have visual control.

I'll check out the latest patch on 28577 and comment there.

#9 in reply to: ↑ 6 ; follow-up: @joedolson
3 years ago

Replying to nacin:

Not all languages have an ISO 639-1 code.

Is it possible to map the languages that don't have a code to another language with similar pronunciation rules? Do you have a list of the current translation options that don't have codes?

#10 in reply to: ↑ 9 @johnbillion
3 years ago

Replying to joedolson:

Do you have a list of the current translation options that don't have codes?

According to GlotPress, the following languages don't have an ISO 639-1 code:

  • Asturian
  • Catalan (Balear)
  • Kashubian
  • Greek (Polytonic)
  • Swiss German
  • Hawaiian
  • Hazaragi
  • Iloko
  • Mari (Meadow)
  • Maori
  • Mari (Hill)
  • Mirandese
  • Rohingya
  • Rusyn
  • Aromanian
  • Sakha
  • Sanskrit
  • Klingon
  • Tamazight (Central Atlas)
  • Udmurt
  • Venetian
  • Mingrelian

#11 @JDTrower
3 years ago

Is there a reason why ISO 639-1 has to be used and not for example ISO 639-3? From a quick search, I couldn't find an ISO 639-3 code for Catalan (Balear) [although Catalan by itself does], Greek (Polytonic) [although Greek modern and Greek ancient have codes], and Mari (Meadow) and Mari (Hill) [although Mari has three different ISO 639-3 codes).

All the rest of the languages that johnbillion listed have ISO 639-3 codes.

This ticket was mentioned in IRC in #wordpress-dev by DrewAPicture. View the logs.


3 years ago

#13 @DrewAPicture
3 years ago

  • Keywords dev-feedback added

Can we get a consensus on what's left here? Maybe finding a middle ground on language coverage?

#14 @joedolson
3 years ago

The official guidelines on what you should use for language codes are quite complicated: ISO-639 2-letter codes if available, 3-letter codes if not. I believe that this is because of support; the 2-letter codes are more globally supported than the 3-letter codes.

If we use the ISO-639-3 codes, that would give us the greatest coverage for language pronunciation. If a language doesn't have an ISO-639 code, then we would just have to fallback to whatever we could; screen readers aren't going to support those missing codes anyway, so it's not a realistic option to provide the "right" code - it doesn't exist.

I haven't looked at the data in the translations API; is it reasonable to have a fallback series: ISO 639-1 if available, ISO 639-3 if not?

#15 in reply to: ↑ description @johnbillion
3 years ago

  • Resolution set to fixed
  • Status changed from new to closed

Replying to joedolson:

1) Button to move forward has no text. There needs to be some kind of text in the step button for screen reader users to know what's happening. Patch adds text 'Set'.

Fixed in r29372.

2) Focus is being manipulated so that radio buttons can only be navigated when fieldset is focused, but the fieldset can't receive focus from the keyboard. Patch adds tabindex='-1' so that the fieldset can receive focus.

The focus is no longer being manipulated, also since r29372.

3) Languages are written in native language, but have no lang attribute to inform screen reader how to pronounce the language. Patch adds lang="$language['language']" -- this will not be complete, because the WP language profiles do not match the ISO 639 language code list http://www.loc.gov/standards/iso639-2/php/code_list.php. Might be a good idea to set up a language reference so that these can be mapped appropriately.

Fixed in r29260.

4) For sighted keyboard users, navigating the language list does not trigger scrolling in the language container. This means that any user who can't use a mouse to navigate the list will not be able to select their language if it's outside the default visible options. Needs: trigger scrolling one keypress. And I'm not sure how to do that.

Also fixed in r29372 as we're now using a <select>.

The remaining issue is regarding the languages listed in my comment above which don't have ISO 639-1 codes. This is closely related to language variants (formal, informal, etc). See #15677.

I'm going to close this as fixed. The ISO codes / language variant issue can be covered in #15677.

Note: See TracTickets for help on using tickets.