Category dropdown does not meet WCAG 2.2 A on windows and some linux systems

[adrock42]

Using WP 6.8.1 on Windows 11 with up-to-date browsers in a brand new local WP build spun up for testing

1. create a website using WordPress
2. create some post categories
3. create some posts and assign the posts to the categories

when using blocks

4. add a categories block to a template

when using the classic widgets plugin

4. add the categories widget to a side bar

5. in Windows chrome or Firefox, or linux chromium navigate to the frontend page where the categories widget or block lives.
6. Using a keyboard, tab to the categories dropdown (<select>) and hit enter to display the dropdown options
7. Click arrow down to select an option
8. Click escape

at this point the user is taken to the page of the category that was selected
to meet the WCAG criterion, the user should remain on the same page and the option cleared.

WCAG mentions Success Criterion 3.2.2 On Input
Changing the setting of any user interface component does not automatically cause a change of context unless the user has been advised of the behavior before using the component.

here is an example of a similar failure ​https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/F9

Keeping the currently selected option and not removing the selection seems like an OS-Specific behavior. I am not observing this behavior on OSX, but I do see it on Windows in chrome and firefox and in elementary OS in chromium

this appears to all come from the JS injected here
​https://github.com/WordPress/WordPress/blob/master/wp-includes/blocks/categories.php#L100
​https://github.com/WordPress/WordPress/blob/master/wp-includes/widgets/class-wp-widget-categories.php#L99

possible fixes are a big ole "GO" button (ick), or clearing the selection before the select.onChange is dispatched

[sabernhardt]

Related: #40925

[joedolson]

This is a long known issue. But it's definitely worth addressing again, as browser handling of events has changed some since we last discussed it.

At this point, we may be able to simply change the event to trigger on onSelect instead of onChange. This will subtly break the past behavior, since the event will fire later, so it's possibly something we should ship early and monitor for feedback.

But it's something I've wanted to change for a long time, so I'm going to go ahead and milestone it and see what we can do.