Opened 11 years ago
Closed 11 years ago
#26633 closed defect (bug) (fixed)
Customizer form submission prevention impairs accessibility of links in customizer controls
Reported by: | westonruter | Owned by: | ocean90 |
---|---|---|---|
Milestone: | 3.9 | Priority: | normal |
Severity: | normal | Version: | 3.4 |
Component: | Customize | Keywords: | has-patch needs-testing |
Focuses: | accessibility | Cc: |
Description
In working on the Widget Customizer feature-as-plugin, we're embedding the wp_widget_control()
directly inside of a Customizer control. A widget control includes not only input
elements, but also buttons and links which serve as buttons (e.g. Update, Delete, and Close). We're listening for click
events on these buttons and pseudo-buttons to then update the widget, close the widget control form, and remove the widget entirely. However, when attempting to invoke those links by hitting Enter on the keyboard, the click
handler is not fired as the normal default action. I narrowed the problem down to this:
// Prevent the form from saving when enter is pressed. $('#customize-controls').on( 'keydown', function( e ) { if ( $( e.target ).is('textarea') ) return; if ( 13 === e.which ) // Enter e.preventDefault(); });
The condition for preventDefault
is matching more often than it should, namely it should only preventDefault
if Enter was pressed inside of a non-button input
element, as this should be the only kind of element which triggers a form submit.
Here is a reworked keydown
event handler which doesn't disable click
events from being triggered when they should be:
// Prevent the form from saving when enter is pressed on an input element. $( '#customize-controls' ).on( 'keydown', function( e ) { var is_enter = ( 13 === e.which ); if ( is_enter && $( e.target ).is( 'input:not([type=button])' ) ) { e.preventDefault(); } } );
Introduced in r20035 from #19910. Related to #20879.
/cc koopersmith
Attachments (3)
Change History (12)
@
11 years ago
Patch to prevent over-prevention of default actions when hitting Enter in a customizer control
#4
@
11 years ago
- Keywords needs-patch added; has-patch removed
I was only one click away from a commit when I noticed, that an enter on a select element triggers a form submit too.
#5
@
11 years ago
- Keywords has-patch needs-testing added; needs-patch removed
26633.patch checks additionally if it's a select element.
This ticket was mentioned in IRC in #wordpress-dev by ocean90. View the logs.
11 years ago
#7
@
11 years ago
@ocean90: Good catch! Your revised patch prevents submission when hitting Enter on select
elements, but the widgets are now accessible with the keyboard. Should we also prevent default events on input[type=submit]
buttons? I didn't think any customizer control should ever contain those, so I didn't check for that.
Plugin which demonstrates the keyboard-accessibility problem