Make WordPress Core

Opened 6 years ago

Last modified 2 months ago

#40925 accepted task (blessed)

Review the usage of the change event on select elements

Reported by: afercia's profile afercia Owned by: joedolson's profile joedolson
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-screenshots a11y-task
Focuses: ui, accessibility Cc:


See also #31634

The change event can be problematic when used on select elements because browsers fire the event in different ways across different platforms. In this ticket I'll try to clarify what this difference is, why it matters for keyboard users, and why some actions shouldn't be triggered when a select option gets selected.

On macOS, when using the keyboard to navigate content and a select element gets focused, using the arrow keys always opens the select "drop-down":

This behavior allows users to explore the content of the select, scroll through the options, and select an option pressing Enter or Spacebar. This way, the change event fires after an explicit user action.

Instead, on Windows using the arrow keys on a select doesn't automatically open the "drop-down". To clarify what happens, I've made a short video using the Archives and Categories widgets as an example:

Historically, this behavior was typical of all browsers on Windows, except Firefox. However, a recent change made Firefox behave like all the other browsers. For more details, see

Since the drop-down doesn't open (it does only when pressing Alt+Down arrow), it's hard to scroll the list of options without firing the event at each arrow keys press. Users would need to explore the content of the select before making a choice, and to do so they use the arrow keys. However, while exploring the select content, the action associated to the change event runs. In the case of these widgets, the action triggers a full page reload.

Actions that have a big impact like a full page reload or a complete change of context should only be triggered after an intentional choice of the user, i.e. when pressing a button close to the select. In other cases, when the action triggers minor changes, using the change event could be OK. The best option would probably be to evaluate the interaction on a case by case basis.

There are a few places in WordPress where the change event is used this way, not pretending to be a complete list, here's some of them:
Media views:

  • Filter by type
  • Filter by date


  • Menu > Menu locations
  • Static front page > A static page

Change History (19)

#1 @afercia
6 years ago

  • Focuses accessibility added

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

6 years ago

#3 @afercia
6 years ago

  • Milestone changed from Awaiting Review to Future Release

Moving to future release as per today's bug scrub.

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

6 years ago

#5 @afercia
6 years ago

Related: #25103

This ticket was mentioned in Slack in #accessibility by afercia. View the logs.

6 years ago

#7 @afercia
6 years ago

  • Milestone Future Release deleted
  • Type changed from defect (bug) to task (blessed)

Discussed during today's accessibility bug-scrub and agreed this is something that should be better handled as a task, as done for example with the series of tickets related to the title attribute:
There’s the need to find instances, touch several parts of the codebase, etc. and one ticket for each instance would be a better approach.

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.

6 years ago

#9 @benjamingaunt
6 years ago

#43237 was marked as a duplicate.

#10 @afercia
6 years ago

FOr the Categories and Archives widgets, see also previous discussion on #18650.

#11 @SergeyBiryukov
6 years ago

  • Milestone set to Future Release

#12 @afercia
6 years ago

Just wanted to quote the related specification, for clarity:

The change event occurs --> when a control loses the input focus and its value has been modified since gaining focus <--. This event is valid for INPUT, SELECT, and TEXTAREA. element.

As said, historically many browsers have implemented it in an non-conforming way.

This ticket was mentioned in Slack in #accessibility by rianrietveld. View the logs.

5 years ago

#14 @afercia
5 years ago

  • Keywords a11y-task added

#15 @afercia
4 years ago

Web Content Accessibility Guidelines (WCAG) references:

Success Criterion 3.2.2: On Input

Success Criterion 3.2.5: Change on Request

Using an onchange event on a select element without causing a change of context

Describing what will happen before a change to a form control that causes a change of context to occur is made

Providing a submit button to initiate a change of context

WCAG definition of "change of context"

Last edited 4 years ago by afercia (previous) (diff)

This ticket was mentioned in Slack in #design by garrett-eclipse. View the logs.

3 years ago

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.

2 years ago

#18 @joedolson
10 months ago

  • Owner set to joedolson
  • Status changed from new to accepted

This ticket was mentioned in Slack in #accessibility by joedolson. View the logs.

2 months ago

Note: See TracTickets for help on using tickets.