attr( { role: 'button', tabIndex: 0 } ) and add return keypress events to all of them.

Also dialogs should have role = dialog and buttons that pop up dialogs should have aria-haspopup

It's not really an enhancement, since it is preventing proper accessibility. But so long as it is looked at and fixed, that's what really matters :)

• Bug 51913 has been marked as a duplicate of this bug. ***

• Bug 51918 has been marked as a duplicate of this bug. ***

From bug 50897 comment 2:

In the old editor, I would simply use TAB to reach the edit summary, type my
edit summary and press ENTER to activate the "Save page" button and save. If I
wanted to mark the edit minor, then I could type my edit summary, press TAB,
SPACE, and then ENTER to "Save page".

I can see that the new box for entering an edit summary allows newlines to be
entered. I am not sure this is a good idea, because I just used a WSYIWYG
editor and now "What I see" - well-formatted paragraphs describing my edit - is
not going to be "what I get" - everything smashed on one line in the article
history. But that is perhaps grist for another bug mill.

It seems that the "Save page" button never receives caret focus if I use TAB to
try to get there. This would seem to have accessibility ramifications.

There seem to be two distinct requests:

• getting from the editing "surface area" to the edit summary input (with a tab key?)

• getting from the edit summary input to the save page or review changes buttons (with a tab key)

Change 75594 had a related patch set uploaded by Esanders:
Makes ButtonWidgets more accessible

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

Patch above should fix original bug. Issue of tabbing from surface to 'Save page' is also partly fixed, but because of DOM order you have to shift+tab. If we want to switch these round, please open a new bug.

Change 75594 merged by jenkins-bot:
Make ButtonWidgets more accessible

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

Fixed and will get deployed in a few minutes.

The current tab order is pants, and is not what was requested in comment 1 or comment 5.

From the edit summary box, the tab order is now:

1. the link "minor edit" beside the 'minor edit' checkbox.
2. "Save Page" button
3. "Review your changes" button

Then three tabs for the links in the footer of this windows.

Tabbing to the _link_ "minor edit" is a bug in the current implementation.

Unless there is a good reason to do otherwise, the tab order should be the same as the source editor (muscle memory). See also bug 51918 for a tab order request.

• Bug 52080 has been marked as a duplicate of this bug. ***

This bug is fixed. Will use bug 51918 to track changes to tab order instead.

This appears to be broken again- can't tab to "save page" in the current release. Prefer to reopen this bug or file a new one?

I can on enwiki, MediaWiki.org and Beta Labs – where are you having this issue?

Enwiki, Firefox nightly on Mac. But does seem to work on office with Chrome.

Hmm, yeah, this has regressed for Firefox. Yay for browser bugs. Will follow-up on bug 51918.