Get WordPress

Make WordPress Core

Opened 5 years ago

Last modified 43 hours ago

#48996 new defect (bug)

Add lang attribute to the content in the backend

Reported by: chouby's profile Chouby Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.7
Component: I18N Keywords:
Focuses: accessibility Cc:

Description

Since WordPress 4.7, it is possible for a user to display the backend in a language different than the current site's language. In this case, the html 'lang' attribute is set to the user's language. I am not an accessibility expert but I expect that this causes an issue for screen readers as the site's content will be read with a wrong language.

Also I am not sure if this is an issue to often switch the language of a screen reader.

Anyway, I propose to add a 'lang' attribute to all the html tags displaying content. This 'lang' attribute must be filterable for multilingual plugins being able to select the correct language for each content.

Change History (9)

#1 @audrasjb
5 years ago

  • Keywords reporter-feedback added

Hi @Chouby and thank you for opening this ticket,

I think there is already a lang attribute added in the <body> tag. We don't need to add it to each HTML tag if the lang of this content is actually the same than the language attribute provided in <body lang="xx">. Adding lang attribute to specific HTML tags is only necessary if their content is in a different language.

#2 @Chouby
5 years ago

Hi @audrasjb,

Yes I am referring to backend pages mixing languages. It will be probably clearer with an example. Let say that the site's language defined in Settings > General is set to en_US. Then I select fr_FR in my user profile. The backend language is set to French and the html tag is correctly set to:

<html xmlns="http://www.w3.org/1999/xhtml" class="wp-toolbar" lang="fr-FR">

Now if I go to the posts list table, there is an issue. All the posts titles, categories, tags will be read in French, although the content of the website is in English. I would expect that the html tags wrapping them is assigned a lang="en_US" attribute so that they are read in the correct language.

I took this example because it's probably one of the harder to handle. In this page, the language would very often switch between the content's language and the backend language. I am not sure that's correctly handled by screeen readers.

#3 @sabernhardt
5 years ago

I see: this would accommodate a single-language site where an editor prefers/needs a different language in the backend, and a filter would also help plugins make adjustments for multi-lingual sites.

So far, I noticed that we should replace the aria-label for a post title link (perhaps using screen-reader-text span instead?). The label currently contains both the post's language (English in following example) and the editor's preferred language (French):

<a class="row-title" href="http://localhost/wp3/wp-admin/post.php?post=1&amp;action=edit" aria-label="«&nbsp;Hello world!&nbsp;» (Modifier)">Hello world!</a>

(The same also occurs on Pages, Categories and Tags title/name links.)

Below is a list of items that could be addressed with customized lang attributes (likely not complete). For this ticket, we might want to focus on the Posts list, and then reuse the filter for any other category we want to tackle on another ticket.

Posts list (verify changes also affect Pages list and Custom Posts list)

  1. Post title link
  2. Links for categories, tags, and custom taxonomy terms
  3. Content added to other columns (usually by a plugin), such as page titles and meta descriptions

Media Editor input fields

  1. Image alt text
  2. Caption
  3. Description

Taxonomy screens

  1. Names and descriptions for any categories, tags and custom taxonomies

Menus and Widgets

  1. Menu item names in menu-item-title span and edit-menu-item-title input, post titles in post list, "original" links
  2. Menu item description
  3. Widget titles
  4. Text widget content (maybe another widget as well, but supporting all widgets could be tricky)

Comments

Setting these to the post's language would not be correct for every comment, though it might be correct often enough to implement the change. (Of course, allowing commenters to set their comment's language would be helpful on the frontend, too, if we want to open a separate ticket to explore that later.)

This ticket was mentioned in ​Slack in #accessibility by afercia. ​View the logs.
4 years ago

#5 @afercia
4 years ago

  • Keywords reporter-feedback removed
  • Milestone changed from Awaiting Review to Future Release

This ticket was discussed during today's accessibility bug-scrub: when WordPress will move towards improving multi-lingual content support, this would be great to tackle. Moving to Future Release for now.

#6 @sabernhardt
4 years ago

Related: #40715 addresses the (classic) TinyMCE editor

This ticket was mentioned in ​Slack in #accessibility by audrasjb. ​View the logs.
4 years ago

#8 @afercia
4 years ago

#40715 was marked as a duplicate.

Note: See TracTickets for help on using tickets.