Should start with Agree
Version: unspecified
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=62764
Description
Description
Details
Details
- Reference
- bz62763
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Fix tab order of buttons | mediawiki/extensions/OAuth | master | +4 -3 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T90925 General authentication improvements for MediaWiki | |||
| Open | None | T86869 Support a nice sso experience with MediaWiki's OAuth | |||
| Open | None | T75062 OAuth permission screen needs redesign for better usability and comprehension | |||
| Resolved | None | T64763 keyboard Tab order in OAuth Confirm dialog starts with Cancel |
Event Timeline
Comment Actions
Change 200753 had a related patch set uploaded (by MarkTraceur):
Fix tabindex and order of buttons
Comment Actions
@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.
Comment Actions
@Jaredzimmerman-WMF it seems that the proposed patch would move the "accept" button to the left.
Comment Actions
@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
Comment Actions
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.
Comment Actions
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.....
Comment Actions
Can't you just float them or use some other positioning trick to make DOM order different from document order?
Comment Actions
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.
Comment Actions
Yes, but I do notice that apparently this broke recently. The Cancel button is now the most right button.
this element is a span around the button now, not the input itself.