Cannot use spacebar to trigger OK button or links in Publish widget (eg. schedule settings)

[Daedalon]

When changing the scheduled publishing time of a post, the OK button after the time fields cannot be triggered by pressing spacebar.

The same applies to all buttons and links in the Publish widget on the Add New / Edit Post page. The Add button in the Tags widget on the same page can be triggered with space since WordPress 3.5.

Steps to repeat:

1. Create a new post by navigating to wp-admin/post-new.php.
2. Click the underlined link in "Publish immediately _Edit_" in the Publish widget.
3. Click the last field (minutes).
4. Press Tab once to move focus to the OK button.
5. Press spacebar.

What happens is the screen scrolling down exactly as if Page Down was pressed.

What should happen is the same that happens when the button (or link) is clicked with mouse, which depends on the button (or link).

Tested on Windows XP & 7 and all the recent Firefoxes I can remember and Internet Explorer 9.

[sayaksarkar]

Tested on Fedora 18 with Firefox 20. Issue persists!

[lessbloat]

Replying to Daedalon:

To be clear, this "scrolling when the spacebar is pressed" functionality is intentional in pretty much every browser.

The case you referenced here is not the only instance where this happens in the admin.

While we don't want to disable the default scrolling functionality for the most part, we might be able to get away with doing it whenever the focus is on a button or a link. 23760.diff detects the spacebar key press when focus is on either a link or a button anywhere in the admin, and treats it like an "enter" keypress.

[lessbloat]

23760.1.diff​ does this just for buttons, if links is taking it too far.

[Daedalon]

Lessbloat: The standard behavior for browsers when pressing spacebar depends on whether a button, textarea, link or input element is focused. This list might not be inconclusive. Scrolling of the page upon the pressing of spacebar should happen only when none of these is focused. WP-admin breaks this standard behavior by scrolling the page on spacebar despite certain elements being focused.

By the look of it, your patch restores the standard functionality, which I find great.

Any idea what caused the non-standard behavior in the first place?

[helen]

Replying to Daedalon:

Any idea what caused the non-standard behavior in the first place?

Standard behavior in a browser when a link is focused is to scroll, not act on it, at least in the browsers I'm testing (Firefox and Chrome, OSX). You're not seeing non-standard behavior - some of the "buttons" are actually links styled to look like buttons. lessbloat's second patch was on my request. Wondering if we are abusing the links-styled-as-buttons thing here.

[sabreuse]

Replying to helen:

Wondering if we are abusing the links-styled-as-buttons thing here.

I think we are -- I'm not sure if we had good reasons for doing that in the first place, but it would be better for accessibility and save us having to write JS for what should be standard behavior if we used <button> where that's what we mean. I'll put a patch together for that approach.

[afercia]

Replying to sabreuse:

Replying to helen:

Wondering if we are abusing the links-styled-as-buttons thing here.

I think we are -- I'm not sure if we had good reasons for doing that in the first place, but it would be better for accessibility and save us having to write JS for what should be standard behavior if we used <button> where that's what we mean.

Definitely yes, that's what the Accessibility Team recommends, see #26504 for background.

[azaozz]

Replying to afercia:

Replying to sabreuse:

Replying to helen:

Wondering if we are abusing the links-styled-as-buttons thing here.

I think we are...

Definitely yes...

As far as I see most links that are styled as buttons can be actual <button>. There are some exceptions for no-js. For example the Preview "button" cannot be a <button> when no-js. It is a link to siteurl?p=123&preview=true that opens in a new tab/window. We can probably have both and show the link/hide the button when no-js.

[afercia]

As pointed out in the comments, some links look like buttons but they're links and the default behavior when pressing Spacebar on a link is scrolling the page. For semantics and accessibility most of these "looking-like-buttons" links should be buttons and there's a ticket for that: #26504.

[afercia]

Gardening tickets, would propose to close this in favor of #26504.

[wonderboymusic]

Closing in favor of #26504