Page MenuHomePhabricator

Increase consistency among instances of the ULS
Open, Needs TriagePublic

Description

Description

The ULS appears in two different places:

ULS in article titlebarULS in site header
Screen Shot 2022-04-05 at 12.54.20 PM.png (1×2 px, 577 KB)
Screen Shot 2022-04-05 at 12.53.53 PM.png (1×2 px, 824 KB)

Currently the keyboard support is inconsistent between those two instances. This task is about increasing consistency.

Noted differences

ULS in article titlebarULS in site header
can be opened with space or enter (when focused)can be opened with enter (when focused)
can use tab to navigate language listtab skips links, cannot be used to navigate language list

Other notes

Universal Language Selector trigger in personal bar (like one on mediawiki.org), language settings cog icon (T52575), and the language selector for the Compact Language Links (T70075) are all keyboard accessible. Recent efforts are made to increase the keyboard accessibility of the panels opened from those triggers.

Language settings panel and its associated 'Display' and 'Input' tabs should be accessible after T52793: Make ULS accessible from keyboard.

As noted, arrow keys serve good role in scrolling the language results panel (once it receives focus), but navigating through the list of languages using keyboard arrows may be desired behavior and certainly one I expected many times as user.

Event Timeline

The patch for T52793: Make ULS accessible from keyboard currently also changes the triggers (e.g. fixing Language selector can be opened using Enter (but not with Space) when trigger has focus).

To me it seems the main issue you are reporting is that from non-CLL entry point it is not possible to tab into the list of languages, is that correct?

To me it seems the main issue you are reporting is that from non-CLL entry point it is not possible to tab into the list of languages, is that correct?

Yes, that is correct.

The other part is being able to use keyboard arrows to navigate through the list of languages (give focus to different language links). But, that is in contrast with current behavior when using arrows, which might be more natural.

Pginer-WMF renamed this task from Make ULS language panel keyboard accessible to Make ULS language panel keyboard accessible at the personal bar .Feb 6 2018, 9:40 AM
tstarling added a subscriber: tstarling.

This is probably a WCAG 2.0 SC 2.1.1 conformance failure. You can type the language name, but if "suggested languages" counts as functionality then it's a violation to not give keyboard access to it.

alexhollender_WMF renamed this task from Make ULS language panel keyboard accessible at the personal bar to Make ULS language panel more keyboard accessible.Apr 4 2022, 7:59 PM

I did some testing and confirmed that the personal tools language button is inconsistent with the article headings language button and has incorrect keyboard navigation behavior.

For comparison:
Language button in article heading (correct behavior)
Language button in personal tools (incorrect behavior)

To clarify what's going on for the language button in personal tools:

Language selector can be opened using Enter (but not with Space) when trigger has focus

Space key doesn't work because the selector is a link element. This is a Vector issue, it should be a button element.

Clicking on the language results panel (on the panel itself, not on any language link) gives ability to use keyboard arrows, page up/down and home/end keys, but there doesn't seem to be the way to get focus for any of the languages on the list

You can kind of tab to the language links, but it has a very odd behavior where it skips a large number of links, leaving a large majority inaccessible.

When input field has focus, tabbing leads you away from the ULS panel altogether

I believe whats happening is that the focus is leaving the ULS panel when all the elements have been tabbed through. This actually occurs with both the personal tools language button and the article tools language button, it's just more obvious with the personal tools one because of the aforementioned issue links being skipped on tab.

One solution could be to ensure the ULS panel works like a dialog modal, which traps focus inside the overlay. This should be a separate ticket however, as there are other requirements with dialog modals like the ability to close the dialog via keyboard and a button, so there would be other discussion required.

alexhollender_WMF renamed this task from Make ULS language panel more keyboard accessible to Increase consistency among instances of the ULS.Apr 5 2022, 5:03 PM
alexhollender_WMF updated the task description. (Show Details)

I've updated the task description to be more clear, including a table of noted differences between the ULS in the article titlebar and the ULS in the site header.

There was one point that I couldn't quite understand. If anyone else better understands this please add it to the table:

ULS in personal bar:
Once the focus is moved from input field to language list, scrolling works fine with keyboard arrows, page up/down and home/end keys

ULS in site header:
Clicking on the language results panel (on the panel itself, not on any language link) gives ability to use keyboard arrows, page up/down and home/end keys, but there doesn't seem to be the way to get focus for any of the languages on the list

I've updated the task description to be more clear, including a table of noted differences between the ULS in the article titlebar and the ULS in the site header.

There was one point that I couldn't quite understand. If anyone else better understands this please add it to the table:

ULS in personal bar:
Once the focus is moved from input field to language list, scrolling works fine with keyboard arrows, page up/down and home/end keys

ULS in site header:
Clicking on the language results panel (on the panel itself, not on any language link) gives ability to use keyboard arrows, page up/down and home/end keys, but there doesn't seem to be the way to get focus for any of the languages on the list

Taking apart the use of arrows to navigate the list instead of scrolling, it which is covered in T187964, my understanding is that the remaining part of this ticket would be about the ways to act on the button with the keyboard where space is used in one context but not on the other. For this, I think we may want to follow standard button behaviour. When trying to check which may it be I noticed that OOUI buttons seem to be triggered with enter (not space) and Codex buttons seem to be triggered with space (not enter) based on their demos. I'll try to figure out which may be the intended standard.

It seems that the standard is that "a true button can be fired by <space> and <enter>", which is also a WCAG guideline.

This is still a problem btw.

  1. The button is a link
  2. Because it is a link, it does not handle space / enter correctly
  3. No indication that this will launch a popup dialog
  4. Focus inside ULS is still a problem