WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 5 weeks ago

#40925 new task (blessed)

Review the usage of the change event on select elements

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

Description

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":

https://cldup.com/rU6roN4wAO.png

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: https://cloudup.com/iuFxQ7CkA7k

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 https://bugzilla.mozilla.org/show_bug.cgi?id=1350700

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

Customizer

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

Change History (15)

#1 @afercia
2 years ago

  • Focuses accessibility added

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


2 years ago

#3 @afercia
2 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.


2 years ago

#5 @afercia
2 years ago

Related: #25103

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


19 months ago

#7 @afercia
19 months 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: https://core.trac.wordpress.org/query?keywords=~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.


18 months ago

#9 @benjamingaunt
18 months ago

#43237 was marked as a duplicate.

#10 @afercia
18 months ago

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

#11 @SergeyBiryukov
17 months ago

  • Milestone set to Future Release

#12 @afercia
15 months ago

Just wanted to quote the related specification, for clarity:

https://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-keyevents

change
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.


10 months ago

#14 @afercia
10 months ago

  • Keywords a11y-task added

#15 @afercia
5 weeks ago

Web Content Accessibility Guidelines (WCAG) references:

Success Criterion 3.2.2: On Input
https://www.w3.org/WAI/WCAG21/Understanding/on-input

Success Criterion 3.2.5: Change on Request
https://www.w3.org/WAI/WCAG21/Understanding/change-on-request

Using an onchange event on a select element without causing a change of context
https://www.w3.org/WAI/WCAG21/Techniques/client-side-script/SCR19

Describing what will happen before a change to a form control that causes a change of context to occur is made
https://www.w3.org/WAI/WCAG21/Techniques/general/G13

Providing a submit button to initiate a change of context
https://www.w3.org/WAI/WCAG21/Techniques/general/G80

WCAG definition of "change of context"
https://www.w3.org/TR/WCAG21/#dfn-change-of-context

Last edited 5 weeks ago by afercia (previous) (diff)
Note: See TracTickets for help on using tickets.