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

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:

image.png (986×1 px, 177 KB)

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.

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.

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

RHo added subscribers: MMiller_WMF, RHo.

hi @MMiller_WMF - it sounds like that making the "Highlight results" button keyboard accessible involves either modifying some current key detection code in place (per @kostajh's comment T191860#5105303) or a fairly big change to the implemented design (per @Tgr's comment T191860#5429046).

Pending any ideas from @Volker_E, please provide your thoughts on whether we should invest time exploring a new design or look at re-coding the existing UI to fix.

@Tgr It's not a normal dropdown, it's a custom interface element. And as soon as you put buttons, that have direct impact on the current view into an overlay – here contextually represented as something similar to a dropdown, but could also be similar to a dialog representation – they need to be keyboard accessible.

Keyboard navigation is also not necessarily or causatively connected to visual handicaps, but to motoric. Not sure about reason for the ARIA listbox reference…?

Is being tab-able the best solution? Due to the length and the many interactive elements, it seems that a different tab order and providing tabs only in certain ways is the most useful way.

Currently non of those highlight buttons are reachable at all.

@kostajh -- could you please spend like 10 minutes thinking about how long your proposed hack from T191860#5105303 would take to implement?

@kostajh -- could you please spend like 10 minutes thinking about how long your proposed hack from T191860#5105303 would take to implement?

I don't think what I proposed then would really satisfy this task, unfortunately.

Moving off current sprint board given this is not happening soon