I'm not sure about the scope of this ticket. Some of ULS accessibility concerns are raised in T186551.
If I understand what you describe correctly, you have discovered more info that could be added to existing ticket. No need to have them separate, in my opinion.

What I have observed is that once ULS is opened, you get focus on input field. Pressing tab key on keyboard can lead you away completely from ULS and usually in disruptive manner. Navigating to cog icon, pressing enter, and tabbing again to dotdotdot button, opening it by pressing enter, gives ULS with input field focused. Pressing tab key at that point throws you away to top of the page.

One case where tabbing while having focus on input field works is CLL. That change in behavior is mysterious and needs to be investigated.

Btw, I have realized you probably know what tabbing and focus is, so some parts of my comment at T186195#4012261 are futile.

@Jdlrobson @ovasileva @Pginer-WMF @Amire80: we previously discussed improvements to keyboard support/accessibility for the ULS menu. We agreed that the new ULS would have improved support. However, since the new ULS will not be available before the launch of the desktop improvements project, and the new placement of the ULS combined with the lack of compact language links means the ULS will be used much more, I think it would be great if we could add this minimal amount of keyboard support before launching.

In T187964#7830075, @Jdlrobson wrote:

Presumably, this would benefit from a meeting with the language team since the web team has limited experience with this extension and would need support for code review (and possibly development).

+1 to this. @Pginer-WMF - I can set up a meeting for all of us to discuss, but it seems this is better aligned with the Language team's work currently.

From what I understand from T186551, the main issue was that the keyboard behavior for the personal tools language button isn't consistent with the article heading language button. The ability to use up/down keys in the language list was an additional suggestion, and it's also a new behavior that isn't current present in any of the language buttons. While I think it's a good idea to break out up/down arrow support into a new ticket and look into that, I'm a bit worried the original issue of consistency will get lost in this convo. In my opinion, that will have a larger impact to the accessibility of the personal tools language button, and should be more straightforward as it's fixing a bug.

On the topic of adding up/down arrow support, I would definitely be interested in hearing from the Language team. The ULS currently isn't built with as a combobox (which should have arrow key support), and I'm curious to know if there's other context that we are missing. In particular I know the ULS has additional "Display settings" and "Input settings" buttons, and I'm not sure how that might impact the decision to add arrow support.

In T187964#7832537, @bwang wrote:

From what I understand from T186551, the main issue was that the keyboard behavior for the personal tools language button isn't consistent with the article heading language button.

what from the task description is leading to this understanding? I didn't see anything about consistency between two different instances of the ULS panel, and was confused as to why the task called out "ULS in the personal bar" specifically, which is why I renamed this task from Make ULS language panel keyboard accessible at the personal bar to Make ULS language panel more keyboard accessible

While I think it's a good idea to break out up/down arrow support into a new ticket and look into that, I'm a bit worried the original issue of consistency will get lost in this convo.

Any changes in keyboard support we make to the ULS should apply to every instance of the ULS (i.e. regardless of if it appears in the site header, or near the article title).

All the bullet points under

"ULS in personal bar has limited keyboard accessibility:"

in T186551 are issues unique to the personal tools language button.
The task is not very clear though, as it mentions arrow key support a lot which I think is a separate issue. I think it's acceptable (but not ideal) for the language links to be accessible via tab, but right now the personal tools language button doesn't even have that.

I posted a comment with videos that might illustrate this better.

@bwang gotcha, thanks for clarifying that. I was misunderstanding that task.

I think it's okay to have this as a sub-task, and just make sure that the update we make here applies to both instances.

Support for up/down keys makes perfect sense in the language selection process. In addition to accessibility improvements, it seems specially convenient when searching for a language and selecting one of the options filtered below (with searching, the user switches to use the keyboard and makes sense to support completing the task without having to leave it or writing more than needed). This was considered for the new language selector, and as mentioned considering the blockers for the new one, it makes sense to explore how to support it in the current one.

I agree it's a good idea to support up/down keys for the ULS panel, but I wanted to add that I'm wary of a situation where we tack on JS to support up/down keys without considering how this component fits into the WAI-ARIA authoring practices.

The behavior described in this task suggests the ULS should be implemented as a combobox widget, which has a set of expected semantics and keyboard/screenreader behaviors. Because the ULS panel doesn't make use of any of these best practices, adding this behavior could potentially make the experience worse for screen reader users. We'd also need to look into how ULS specific UI fits into the combobox spec (i.e. the labels in the search results).

While I do think just adding the up/down behavior would be useful for sighted keyboard users, I think ideally we can approach the accessibility of the ULS panel more holistically. Of course, this increases the scope of the work as well which is also an important consideration.

Change 843938 had a related patch set uploaded (by Nik Gkountas; author: Nik Gkountas):

[mediawiki/extensions/UniversalLanguageSelector@master] Enable up/down keys for navigating the ULS menu

https://gerrit.wikimedia.org/r/843938

Change 843938 abandoned by Nik Gkountas:

[mediawiki/extensions/UniversalLanguageSelector@master] Enable up/down keys for navigating the ULS menu

Reason:

Abandoned since changes to lib/* should go to upstream first. The code for this patch has been moved to a pull request here: https://github.com/wikimedia/jquery.uls/pull/435

https://gerrit.wikimedia.org/r/843938

@ngkountas and I have been working on a patch to add this functionality to jquery.uls. The PR can be reviewed on GitHub.

I've recorded a brief demo with some commentary. You can also test the change on this URL: https://demos.thecurlybraces.com/jquery.uls/examples/index.html

A few notes:

• There is a minor bug that I go over in the demo related to the interaction with mouse hovering + up / down arrow key usage.
• Once I started using the up / down arrows, I instinctively tried using the side arrow keys as well but that does not work currently. Its not easy to implement as language items are present in different unordered lists.

In T187964#8504488, @abi_ wrote:

@ngkountas and I have been working on a patch to add this functionality to jquery.uls. The PR can be reviewed on GitHub.

I've recorded a brief demo with some commentary. You can also test the change on this URL: https://demos.thecurlybraces.com/jquery.uls/examples/index.html

A few notes:

• There is a minor bug that I go over in the demo related to the interaction with mouse hovering + up / down arrow key usage.
• Once I started using the up / down arrows, I instinctively tried using the side arrow keys as well but that does not work currently. Its not easy to implement as language items are present in different unordered lists.

Thanks for sharing the demo (recorded and interactive!). Overall it looks good and it solves the main usecase of a keyboard-only interaction (e.g., searching and using arrows to select an option down the list). Some considerations:

• Right now, when keys are pressed, the user is acting on both the search string and the highlighted elements at the same time. When pressing the up key to navigate the list, the input cursor moves to the begining of the search query which is unexpected. In comparison, Google and Yandex translate selectors have a more polished behaviour by either: (Google) removing the input focus from search as arrows are used (returning to it when the user types again, important for fluency), or (Yandex) keeping the input active but not affected by the up/down arrows. This is not a big issue, but just wanted to check if there is a simple way to polish this behaviour in a similar way.

• Regarding cursor hovering, I don't think it is a big issue since it is consistent with the user actions. Ideally, cursor highlight could disappear as user uses arrow. However, it is expected to be self-explanatory why both elements are highlighted.

• Regarding lateral arrows, I don't think it is a big limitation. I'd consider solving it only once we have a clear answer for not affecting the search string cursor position, which can be more problematic in this case.

In T187964#8518953, @Pginer-WMF wrote:

Thanks for sharing the demo (recorded and interactive!). Overall it looks good and it solves the main usecase of a keyboard-only interaction (e.g., searching and using arrows to select an option down the list). Some considerations:

• Right now, when keys are pressed, the user is acting on both the search string and the highlighted elements at the same time. When pressing the up key to navigate the list, the input cursor moves to the begining of the search query which is unexpected. In comparison, Google and Yandex translate selectors have a more polished behaviour by either: (Google) removing the input focus from search as arrows are used (returning to it when the user types again, important for fluency), or (Yandex) keeping the input active but not affected by the up/down arrows. This is not a big issue, but just wanted to check if there is a simple way to polish this behaviour in a similar way.

Thanks, I somehow missed that. I've fixed this issue by following the Yandex approach.

You can see the updated version on https://demos.thecurlybraces.com/jquery.uls/examples/index.html.

As you mentioned, I'm not planning to work on the other two issues since we eventually want to move to a new language selector.

Perfect. The updated version works great!
Thanks @abi_

Need to update the jquery.uls library in the ULS extension.

Change 880569 had a related patch set uploaded (by Abijeet Patro; author: Abijeet Patro):

[mediawiki/extensions/UniversalLanguageSelector@master] Update jQuery.uls to add support for up/down navigation of languages

https://gerrit.wikimedia.org/r/880569

Change 880569 merged by jenkins-bot:

[mediawiki/extensions/UniversalLanguageSelector@master] Update jQuery.uls to add support for up/down navigation of languages

https://gerrit.wikimedia.org/r/880569

Feature is deployed on translatewiki.net. Can be tested on: https://translatewiki.net/wiki/Group_descriptions

Leaving the task open for a few days in order to get feedback from users on Wikimedia sites.