Page MenuHomePhabricator

Buttons in FilterMenuHeaderWidget like “Highlight results“ are not keyboard accessible
Open, Needs TriagePublic


Currently, buttons in FilterMenuHeaderWidget like “Highlight results“ are not keyboard accessible.

Expected result:
Ability to tab into buttons like back button or “Highlight results” button.

Event Timeline

Volker_E created this task.Apr 9 2018, 11:39 PM
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptApr 9 2018, 11:39 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
kostajh added a project: OOUI.
kostajh added a subscriber: kostajh.

We'll work on this in Q2 (or Q3).

I don't have great ideas about this one. We could modify MenuSelectWidget.prototype.onDocumentKeyDown to use this.findFirstSelectableItem(); when nextItem is null for tab or down arrow when the input field is focused, but we'd also need to change OO.ui.SelectWidget.prototype.selectItem so that the item is considered highlightable, or find some other workaround. There is a TODO there asking // TODO: When should a non-highlightable element be selected?, maybe this is a good use case.

Once that's done, you can go from the input field to navigate down through the checkboxes. This looks kind of weird, since the highlight selection follows the arrow key but then disappears after a few seconds:

Once you're in a mode where you can navigate those items with up and down arrow, we could look for tab key codes and make sure those move on to "Tell us what you think" and then the Highlight button. From there we need to figure out how to get the arrow keys functional in the color selection dropdown.

kostajh removed kostajh as the assignee of this task.Apr 11 2019, 7:37 PM
Tgr added a subscriber: Tgr.Aug 21 2019, 4:32 PM

IMO this could use further design (or rather accessibility expert) input. It seems like for a dropdown menu that contains a lot of stuff, having tab navigate inside the menu would not be expected - the reason to make it a dropdown menu in the first place is to hide that clutter from the common navigation flow in the first place. Also if you are using keyboard navigation because of visual handicaps, how would the menu items themselves be exposed? (Up/down key makes sense but how does the user find out about them?) Googling around it seems like ARIA listbox would be the relevant standard, but applying that to the list seems like a large endeavor.

Tgr added a comment.Aug 23 2019, 11:38 AM

@Volker_E any thoughts on the exact behavior and/or the appropriate markup for assistive tools?