The title attribute as currently just duplicating the text like in the first two actions is actually not helping assistive technology, but negatively impacting f.e. screen readers, as some of them are reading the text twice.
The page actions are altogether not visible when JavaScript is disabled. From an SEO perspective that could have negative impact as well.

In T142527#2538355, @Volker_E wrote:

The page actions are altogether not visible when JavaScript is disabled. From an SEO perspective that could have negative impact as well.

This is fixed as of today. You may need to bust the cache.

(Not easy by any means)

Could some rationale for high priority be added to the task description? I assume it's accessibility related but it's not clear whether the status quo is broken.

I'm moving this to Triaged but Future as it's been in Sprint +1 for almost 5 months.

The culprit is Skin::makeListItem which lives in core. We'd incur technical debt if we do this as written as flagged by ""EDIT: maybe this may not be a good idea. Maybe we should stick to the mark-up defined in core and not add extra classes to li elements.""

Do we want to do this?
Do we plan to improve the code in core?

This part of the description is also unclear and needs clarification:
"Add a link child to the language button."

This would benefit from a talk in front end standards group. Ideally we'd revisit implementation of Skin::makeListItem

Exciting progress here from @Jdrewniak
A few notes:

• The anchor gets role=button assigned, why not making it a button out of box? That would make it simpler for assistive technology
  • Even if disabled, the code is

<a id="" href="" class="mw-ui-icon mw-ui-icon-element mw-ui-icon-minerva-language-switcher language-selector disabled" role="button" title="Read in another language">Read in another language</a>
which the disabled class alone doesn't provide any useful addition to screen readers. It should carry an aria-disabled or if changed to a button a disabled attribute!

@Volker_E I can speak to the button vs link.

The reason this is an <a> and not a <button> is because the default actions, (languages, watchlist, edit) actually all have non-js code-paths as well, which simply link to a different page, e.g. Special:MobileLanguages and ?action=watch.

This is why they should still come down from the server as links and not buttons. However, they should be given the role=button on the client, instead of on the server, which is what happens currently.

I agree the links need the aria-disabled attribute.

Also to your earlier point about the title attribute. I agree the title is being duplicated, and it's probably unnecessary. The reason I left it in there is to provide the "tooltip" when mousing-over on desktop. If you have any thoughts on this pattern, (yay or nay) please share.