Page up/down, home and end don't work for navigating select lists in OOUI
Closed, ResolvedPublicBUG REPORT
Actions

Assigned To

Authored By

	Nikki
	Jun 4 2022, 12:45 PM

Description

List of steps to reproduce (step by step, including full links if applicable):

Open https://commons.wikimedia.org/ while logged out
Open the "Language select" menu
Try using page up/down, home and end to navigate the list
Close that menu
Click "What links here"
Click "What links here"
Open the "Namespace" menu
Try using page up/down, home and end to navigate the list

What happens?:
In an unstyled menu like the language selector, page up/down, home and end can be used for navigating the list. In styled menus, like the one on Special:WhatLinksHere, page up/down, home and end navigate the page instead.

What should have happened instead?:
Page up/down, home and end should navigate through styled lists in the same way they do for unstyled lists.

Software version (if not a Wikimedia wiki), browser information, screenshots, other information, etc.:

Details

Project	Branch	Lines +/-	Subject
mediawiki/core	master	+967 -272	Update OOUI to v0.47.0
oojs/ui	master	+4 -4	Clarify confusing execution order of && vs. \|\| in SelectWidget
oojs/ui	master	+153 -51	SelectWidget: Add Home/End/PageUp/PageDown support, tweak arrow keys wrapping
mediawiki/core	master	+264 -109	Update OOUI to v0.44.2

Customize query in gerrit

Related Objects

Mentioned In: T314731: Major problems with DropdownWidget and JAWS screen reader in OOUI v0.44.2
Mentioned Here: T310556: Menu: Improve keyboard support

Event Timeline

Nikki created this task.Jun 4 2022, 12:45 PM

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 4 2022, 12:45 PM

• Dragonearin closed this task as a duplicate of T40994: Implement a way to index Phabricator tasks by Wikimedia wiki family.Jun 4 2022, 1:33 PM

LucasWerkmeister reopened this task as Open.Jun 4 2022, 1:50 PM

I'm very surprised OOUI didn't have it, we even have type-to-search in select lists, but apparently we forgot about these navigation keys.

I want to note that the desired behavior of page up/down is not obvious. Browsers treat them differently, and in some cases it's pretty silly. Testing on my Windows 10 laptop, I see the following behavior for page up/down on the attached demo page:

long-dropdown.html2 KBDownload

	Chrome	Firefox	Internet Explorer
While dropdown is open	Moves up/down by exactly 19 items (regardless of the height of the dropdown)	Moves up/down by one page, but maximum height of the dropdown is limited, so never more than 19 items	Moves up/down by one page, but maximum height of the dropdown is limited, so never more than 29 items
While dropdown is focused, but closed	Moves up/down by 3 items	Moves up/down by 19 items	Moves up/down by 29 items

(I am not joking, they really behave exactly like this. If anyone would like to try this out on a different operating systems and browsers, it might be interesting to compare the results.)

I'm going to make page up/down for OOUI dropdowns always move by exactly 10 items. It might seem more intuitive to make it move by one page, but it's not obvious what we should do for closed dropdowns in that case, and I think that it'd be weird if two dropdowns on the page acted differently just because we have more or less space to display their select lists. I picked 10 because I like it, but I'm happy to change it if anyone can make a case for a different number.

Also, as I was working on this, I realized that our handling of arrow keys is different from the browsers. Arrow keys would not change the selection while dropdown is closed (they opened it instead), and they would wrap around at the beginning and end of the list. I'm going to change this as well.

Change 805229 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[oojs/ui@master] SelectWidget: Add Home/End/PageUp/PageDown support, tweak arrow keys wrapping

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

gerritbot added a project: Patch-For-Review.Jun 13 2022, 8:21 PM

Test wiki created on Patch demo by Matma Rex using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/9a29514b6d/w/

Also created an OOUI Demos page:
https://patchdemo.wmflabs.org/wikis/9a29514b6d/w/build/ooui/demos

@Nikki You can try out the new behavior at https://patchdemo.wmflabs.org/wikis/9a29514b6d/wiki/Special:WhatLinksHere (and other pages on that wiki), I'd appreciate if you could check if everything is as expected.

We've been tackling a related quest in T310556: Menu: Improve keyboard support, where I've deliberately have removed the <page up> and <page down> key requirement for Select. It seems irrelevant to me to have a screenreader user jumping over list elements without knowing what they are. It also seems somewhat confusing to me what to expect when pressing those buttons in a menu as GUI user. And it seems that browser vendors were as confused as myself looking at @matmarex table above. ;)
The only time this would make sense is a completely regular ordered list and even then it could lead to unexpected results, as the assumption of an ordered list might be disappointed. OTOH one good useful example, that comes to my mind is a year selector (1999, 2000, 2001, 2002, 2003…).

I've also not come across any documentation talking about <page up> and <page down> key support.
Comparing the already linked https://www.w3.org/WAI/ARIA/apg/patterns/listbox/ or https://webaim.org/techniques/keyboard/ there's no indication.

I'm unsure if benefit versus cost supports the edge case for implementing them.

Everything else seems reasonable.
@matmarex So the wrapping around (not going to the beginning or end of list from opposite side) of a native select is the standard: this should inform T310556 as well and we should apply the same logic in OOUI and Codex.

By the way, DropdownWidget (with MenuSectionOptionWidget) acts differently from DropdownWidgets. When pressing <arrow> keys it opens, but doesn't select (assuming through extra nested level)

Change 805229 merged by jenkins-bot:

[oojs/ui@master] SelectWidget: Add Home/End/PageUp/PageDown support, tweak arrow keys wrapping

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

Maintenance_bot removed a project: Patch-For-Review.Jul 18 2022, 11:30 PM

Change 817802 had a related patch set uploaded (by Jforrester; author: Jforrester):

[mediawiki/core@master] Update OOUI to v0.44.2

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

gerritbot added a project: Patch-For-Review.Jul 27 2022, 3:30 PM

Change 817802 merged by jenkins-bot:

[mediawiki/core@master] Update OOUI to v0.44.2

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

Maintenance_bot removed a project: Patch-For-Review.Jul 27 2022, 5:30 PM

matmarex closed this task as Resolved.Jul 27 2022, 5:59 PM

matmarex mentioned this in T314731: Major problems with DropdownWidget and JAWS screen reader in OOUI v0.44.2.Aug 8 2022, 11:00 PM

matmarex edited projects, added OOUI (OOUI-0.44.2); removed OOUI.Aug 9 2022, 6:42 PM

Test wiki on Patch demo by Matma Rex using patch(es) linked to this task was deleted:

~~https://patchdemo.wmflabs.org/wikis/9a29514b6d/w/~~

Change 891579 had a related patch set uploaded (by Thiemo Kreuz (WMDE); author: Thiemo Kreuz (WMDE)):

[oojs/ui@master] Fix wrong execution order of && vs. || in SelectWidget

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

gerritbot added a project: Patch-For-Review.Feb 23 2023, 3:55 PM

Change 891579 merged by jenkins-bot:

[oojs/ui@master] Clarify confusing execution order of && vs. || in SelectWidget

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

Maintenance_bot removed a project: Patch-For-Review.Feb 25 2023, 12:10 AM

Change 921070 had a related patch set uploaded (by VolkerE; author: VolkerE):

[mediawiki/core@master] Update OOUI to v0.47.0

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

gerritbot added a project: Patch-For-Review.Thu, May 18, 5:16 PM

Change 921070 merged by jenkins-bot: