Steps to Reproduce:
Go to: https://doc.wikimedia.org/oojs-ui/master/demos/?page=widgets&theme=wikimediaui&direction=ltr&platform=desktop
Navigate to ButtonSelectWidget section
Use keyboard to navigate in widget
Actual Results:
You can only access by keyboard the selected button.
Expected Results:
Ability to navigate through all buttons inside widget and select them
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Allow tabbing through option widgets | oojs/ui | master | +2 -2 |
@Bkudiess-msft It's actually possible to switch between the buttons in ButtonSelectWidget by arrow keys.
This widget is meant to be used for example in navigation structures, where you switch between certain views. Tabbing through it, would trigger the change immediately, which functionality is not meant to be provided by this widget.
Change 585823 had a related patch set uploaded (by VolkerE; owner: Bkudiess-msft):
[oojs/ui@master] Allow tabbing through option widgets
Change 585823 abandoned by Bkudiess-msft:
Allow tabbing through option widgets
Reason:
Expected behavior
@Volker_E: The previous comments don't explain who or what (task?) exactly this task is stalled on ("If a report is waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on"). Hence resetting task status.
(Smallprint, as general orientation for task management:
If you wanted to express that nobody is currently working on this task, then the assignee should be removed and/or priority could be lowered instead.
If work on this task is blocked by another task, then that other task should be added via Edit Related Tasks... → Edit Subtasks.
If this task is stalled on an upstream project, then the Upstream tag should be added.
If this task requires info from the task reporter, then there should be instructions which info is needed.
If this task needs retesting, then the TestMe tag should be added.
If this task is out of scope and nobody should ever work on this, or nobody else managed to reproduce the situation described here, then it should have the "Declined" status.
If the task is valid but should not appear on some team's workboard, then the team project tag should be removed while the task has another active project tag.)
Thanks @Aklapper. It seems that there's no simple solution without breaking user expectations one way or another. Having <tab>s not being the main navigation trigger might be an issue, specifically if we're not explicit about ability to transition focus in option with <arrow> keys. Leaving as open until somebody comes up with a good idea. Being explicitly verbose about interaction patterns seems like the last resort.