Page MenuHomePhabricator

keyboard Tab order in OAuth Confirm dialog starts with Cancel
Open, MediumPublic

Description

Should start with Agree


Version: unspecified
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=62764

Details

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 2:58 AM
bzimport set Reference to bz62763.
bzimport added a subscriber: Unknown Object (MLST).
  • Bug 67052 has been marked as a duplicate of this bug. ***
Ricordisamoa renamed this task from keyboard Tab order in Oauth Confirm dialog starts with Cancel to keyboard Tab order in OAuth Confirm dialog starts with Cancel.Mar 1 2015, 6:48 AM
Ricordisamoa set Security to None.
bd808 triaged this task as Medium priority.Mar 6 2015, 1:40 AM
bd808 added a subscriber: bd808.

Change 200753 had a related patch set uploaded (by MarkTraceur):
Fix tabindex and order of buttons

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

Pinging Design for the inversion of buttons.

@Ricordisamoa what is the question?

Allow should be the bottom right-most (in LTR) cancel should be to its left. tab index should start with Allow, and move to cancel.

@Jaredzimmerman-WMF it seems that the proposed patch would move the "accept" button to the left.

@Ricordisamoa that is not correct and should be removed from the patch.

@Jaredzimmerman-WMF it doesn't look like we have a good option, then. The way that tabindex works means that things added later in the DOM come later in the tab index, and if I want to change that order, pretty much, I can only do it once, not twice, unless I want to totally confuse every single browser in existence.

Pinging @matmarex who told me to do this, also @TheDJ and @Catrope might have some opinions

For the record, they gave me two or three ideas for "hacks" that would make the tab index "right" and the visual order "right", but it would be totally wrong in every other possible way - stuff like labelling the footer element of the dialog as being RTL, which it isn't, and letting the browser scratch its head over that one.

TheDJ added a comment.Apr 13 2015, 5:00 PM

I think you can only properly do this by using Javascript to set an initial focus.

I guess we should build that into oojs, to prefer the focus to be on enabled constructive buttons when we open a dialog. It can be confusing for screenreaders though, since their focus will jump to that element as well (basically skipping over the content).

Not sure if there is a best of both worlds for this.....

Tgr added a subscriber: Tgr.Apr 13 2015, 7:03 PM

Can't you just float them or use some other positioning trick to make DOM order different from document order?

Tgr claimed this task.May 10 2015, 6:37 PM
In T64763#1204191, @Tgr wrote:

Can't you just float them or use some other positioning trick to make DOM order different from document order?

Went with that after discussing with @TheDJ. Unlike setting focus manually, works with JS disabled as well, and is more natural for screenreaders since tab navigation still starts on the top.

As a side effect, the buttons are on the right side in no-JS mode. If that's a big deal, I can add a container to keep them to the left.

Change 200753 merged by jenkins-bot:
Fix tab order of buttons

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

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 20 2015, 4:53 PM
Danny_B moved this task from Unsorted to Tabindex on the Accessibility board.Jan 22 2016, 9:28 PM
Tgr removed Tgr as the assignee of this task.May 2 2017, 2:34 PM