WordPress.org

Make WordPress Core

Opened 9 years ago

Closed 6 years ago

#23760 closed defect (bug) (wontfix)

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

Reported by: Daedalon Owned by:
Milestone: Priority: normal
Severity: minor Version: 3.5.1
Component: Editor Keywords: close
Focuses: ui, accessibility Cc:

Description

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.

Attachments (2)

23760.diff (490 bytes) - added by lessbloat 8 years ago.
23760.1.diff (487 bytes) - added by lessbloat 8 years ago.

Download all attachments as: .zip

Change History (16)

#1 @sayaksarkar
9 years ago

  • Cc sayaksarkar added

Tested on Fedora 18 with Firefox 20. Issue persists!

@lessbloat
8 years ago

#2 @lessbloat
8 years ago

  • Keywords has-patch added

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
8 years ago

#3 @lessbloat
8 years ago

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

#4 follow-up: @Daedalon
8 years ago

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?

#5 in reply to: ↑ 4 ; follow-up: @helen
8 years ago

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.

#6 @helen
8 years ago

  • Keywords ui-focus added

#7 in reply to: ↑ 5 ; follow-up: @sabreuse
8 years ago

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.

#8 @nacin
8 years ago

  • Component changed from Accessibility to Editor
  • Focuses accessibility added

#9 in reply to: ↑ 7 ; follow-up: @afercia
7 years ago

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.

#10 in reply to: ↑ 9 @azaozz
7 years ago

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.

Last edited 7 years ago by azaozz (previous) (diff)

#11 @iseulde
7 years ago

  • Keywords needs-patch added; has-patch removed

#12 @afercia
7 years ago

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.

#13 @afercia
6 years ago

  • Keywords close added; needs-patch removed

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

#14 @wonderboymusic
6 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Closing in favor of #26504

Note: See TracTickets for help on using tickets.