Impossible to focus OptionsWidgets (ButtonOptionWidget, RadioOptionWidget) by accesskey, tabindex or otherwise
Closed, ResolvedPublic
Actions

Assigned To

Authored By

	Halfak
	May 9 2015, 4:01 PM

Description

Steps to repeat.

Navigate to en.wikipedia.org
Open developer console.
Paste: mw.loader.load('oojs-ui')
Paste: $('body').append((new OO.ui.ButtonSelectWidget({items: [new OO.ui.ButtonOptionWidget({label: "foo", accessKey: "n"}), new OO.ui.ButtonOptionWidget({label: "bar", accessKey: "m"})]})).$element)
Scroll to the bottom of the page and observe "foo" and "bar" button select group
Press [ALT]+"n" and [ALT]+"m" a few times.

Expected:
Buttons would be selected appropriately when accessKeys are pressed

Actual:
Buttons do nothing!

Note that this bug might be related to https://phabricator.wikimedia.org/T98684

Details

	Subject	Repo	Branch	Lines +/-
	SelectWidget/OptionWidget: Implement selecting by accesskey	oojs/ui	master	+88 -43

Customize query in gerrit

Related Objects

Mentioned In: T98681: Add accessKey option TextInputWidget and RadioOptionWidget/RadioInputWidget
T107360: Refactor SelectWidget keyboard accessibility to allow focussing individual OptionWidgets when appropriate (like ButtonSelectWidget)
T98684: OO.ui.ButtonOptionWidget can't be selected from the keyboard (when focused)
Mentioned Here: rGOJUc4d369477a0a: Add AccessKey API to OO.ui.ButtonedElement
T98684: OO.ui.ButtonOptionWidget can't be selected from the keyboard (when focused)
T107360: Refactor SelectWidget keyboard accessibility to allow focussing individual OptionWidgets when appropriate (like ButtonSelectWidget)

Event Timeline

Halfak created this task.May 9 2015, 4:01 PM

Halfak raised the priority of this task from to Needs Triage.

Halfak updated the task description. (Show Details)

Halfak subscribed.

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMay 9 2015, 4:01 PM

matmarex added a project: OOUI.May 9 2015, 4:02 PM

matmarex set Security to None.

Halfak added a project: Accessibility.May 24 2015, 1:25 PM

matmarex mentioned this in T98684: OO.ui.ButtonOptionWidget can't be selected from the keyboard (when focused).Jul 29 2015, 10:17 PM

I posted a longer explanation of why this is so at the sister task T98684#1493032. This is unfortunately impossible to fix without non-trivial changes; see T107360.

matmarex renamed this task from accessKey for ButtonOptionWidget does not work to Impossible to focus OptionsWidgets (ButtonOptionWidget, RadioOptionWidget) by accesskey, tabindex or otherwise.Aug 20 2015, 3:00 PM

matmarex mentioned this in T98681: Add accessKey option TextInputWidget and RadioOptionWidget/RadioInputWidget.

Florian subscribed.Aug 20 2015, 3:39 PM

Danny_B moved this task from Unsorted to Tabindex on the Accessibility board.Jan 22 2016, 9:15 PM

Restricted Application added a subscriber: StudiesWorld. · View Herald TranscriptJan 22 2016, 9:15 PM

Jdforrester-WMF triaged this task as Medium priority.Mar 22 2016, 6:32 PM

In T98685#1493101, @matmarex wrote:

This is unfortunately impossible to fix without non-trivial changes; see T107360.

On further thought, this is not true. Using the accesskey wouldn't have to focus the OptionWidget, it would have to select it in the parent SelectWidget and focus the parent, which probably can be done.

Change 285722 had a related patch set uploaded (by Bartosz Dziewoński):
SelectWidget/OptionWidget: Implement selecting by accesskey

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

gerritbot added a project: Patch-For-Review.Apr 27 2016, 8:44 PM

matmarex moved this task from Tabindex to Access keys / keyboard on the Accessibility board.Apr 27 2016, 8:50 PM

Jdforrester-WMF removed a subtask: T107360: Refactor SelectWidget keyboard accessibility to allow focussing individual OptionWidgets when appropriate (like ButtonSelectWidget).Apr 27 2016, 9:22 PM

@matmarex I'd be interested in the general philosophy behind our accesskey support? Our accessibility guidelines for developers are not mentioning accesskey at all. Citing from http://webaim.org/techniques/keyboard/accesskey accesskey in general is a “good idea implemented poorly” from accessibility perspective. The authors are stating, while it does make sense in a '"closed environment" web application', “some [users] may even be disadvantaged”.
Among the contra arguments are discoverability and language issues or clashing with key combinations already built into assistive technology.

Jdforrester-WMF moved this task from Backlog to Reviewing on the OOUI board.May 23 2016, 5:55 PM

@Volker_E MediaWiki uses accesskeys quite widely, for better of worse, and I imagine it just came up at some point as something OOjs UI was missing. I can't tell you why exactly it was implemented, the commit c4d369477a0a11538372a34d1cb898d72d8b7b9d predates me and doesn't have much explanation.

For example, the "Save page" button in the editor has "S" as the accesskey, and this was carried over to VisualEditor too (that might very well have been the reason why the accesskey feature was implemented in OOjs UI).

I think it's a reasonable feature to have, and we can leave the decision of using it to the application's developer. The general philosophy is that first of all, we strive to make OOjs UI not worse than plain HTML form controls, and I think supporting accesskeys fits with it.

(As a side note, MediaWiki solves some of the specific issues, e.g. making accesskeys localisable to different languages and displaying them in the hover tooltips of links/buttons they are defined for.)

Jdforrester-WMF closed this task as Resolved.May 24 2016, 8:56 PM

Jdforrester-WMF moved this task from Reviewing to OOjs-UI-0.17.3 on the OOUI board.

Jdforrester-WMF edited projects, added OOUI (OOjs-UI-0.17.3); removed OOUI.

Jdforrester-WMF removed a project: Patch-For-Review.

Change 285722 merged by jenkins-bot:
SelectWidget/OptionWidget: Implement selecting by accesskey