Make WordPress Core

Opened 6 weeks ago

Closed 6 weeks ago

Last modified 5 weeks ago

#64169 closed enhancement (wontfix)

Add JavaScript that allows front-end elements with role="button" to be triggered with the spacebar

Reported by: alh0319's profile alh0319 Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Script Loader Keywords: reporter-feedback close
Focuses: accessibility Cc:

Description

Many plugins and themes attempt to remediate accessibility problems by adding role="button" to elements, but fail to add the necessary JavaScript that allows these elements to be triggered with the spacebar, as is expected functionality for buttons.

This seems like an opportunity area for WordPress core to globally fix a specific accessibility problem on many sites with little downside. Here's how WooCommerce did something similar in their core product to avoid having to load this JavaScript in every individual add-on plugin.

Change History (8)

#1 follow-up: @westonruter
6 weeks ago

  • Keywords reporter-feedback added

What would happen if core adds such a global event listener, but then a plugin already has such an event listener? Wouldn't that result in duplicated events being triggered when the spacebar is pressed?

Also, do you have some examples of ecosystem plugins that have this problem?

#2 @johnbillion
6 weeks ago

  • Keywords close added

That change to WooCommerce got reverted. It seems outside the scope of WordPress to try to invisibly fix issues in plugins and themes.

#3 @joedolson
6 weeks ago

I don't think that this kind of automated change is safe without being able to test the effectiveness. This is essentially operating as an accessibility overlay on a large scale, and I think it's a risk that may solve a large number of problems, but also create a host of new ones.

The problem it solves, while a legitimate accessibility issue, is also fairly minor, so I think that the benefits are too small.

The comment in the WooCommerce revert PR is exactly what I'd be concerned about: over aggressive catching of events.

#4 @alh0319
6 weeks ago

  • Resolution set to wontfix
  • Status changed from new to closed

I didn't actually know the answer to

What would happen if core adds such a global event listener, but then a plugin already has such an event listener?

So, I investigated the reported conflict between Woo and Max Mega Menu, and I do think that this may be the case. I think one fires and then the other would fire, which reversed the trigger action. I tried coming up with code to resolve this but wasn't able to without making it specificlly target Max Mega Menu (I.e., I couldn't come up with a generic solution that would apply to anything).

Given this, I think my idea, while good intially is not good in practice and am closing this ticket.

#5 @johnbillion
6 weeks ago

  • Milestone Awaiting Review deleted

Thanks for the discussion @alh0319 !

#6 in reply to: ↑ 1 @SirLouen
5 weeks ago

Replying to westonruter:

What would happen if core adds such a global event listener, but then a plugin already has such an event listener? Wouldn't that result in duplicated events being triggered when the spacebar is pressed?

What would happen if no plugin were adding such an event listener?
Isn't onKeyDown a required event handler?

#7 follow-up: @westonruter
5 weeks ago

If no event listener is added then nothing would happen 😊

#8 in reply to: ↑ 7 @SirLouen
5 weeks ago

Replying to westonruter:

If no event listener is added then nothing would happen 😊

Yes, as if we don't add a single aria label in the whole project. In terms of happening, nothing happens. 😅 But the point is that something actually happens, and do not rely on a 3rd party for that to happen or not happen.

Note: See TracTickets for help on using tickets.