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.

[joedolson]

@whyisjake We've discussed adding a button before, but it has the problem that it will change the visible output for user's existing sites. For any site that's using the current dropdown option, it's designed without a submit button - inserting the button is almost guaranteed to result in a break in their design.

So as much as that's the best actual outcome, it's got a lot of probable side effects.

[joedolson]

I'm not sure what I was thinking suggesting 'onSelect', since that's an unrelated event... I think I was just confusing it with the spec changes in behavior in the onchange event since this was previously discussed...

However, it sounds like the issue is particularly demonstrating a variation in how browsers handle the esc action. This is something we should be able to handle, just be listening for the esc key and preventing action if that's the keypress.

This modifies the scripting for the category and archives widget dropdown select to prevent esc from submitting the form.

Because the key event is not part of the e object for a change event, this requires adding three separate event listeners: a listener in keydown to notice the esc key and record it in an attribute on the element; a listener on click to remove the attribute if the user later uses a mouse to activate the form; and modifications to the existing onchange listener to handle navigation.

The onchange event now appears to require a short delay before execution to ensure that the DOM change is observed.

Trac ticket: https://core.trac.wordpress.org/ticket/63531

[joedolson]

I added an alternate solution that handles the esc key for browsers that submit the change event in this scenario.

[joedolson]

Because the key pressed isn't available in the change event, this updates the code to add an additional eventlistener on keypress that records whether the esc key was pressed and prevents the change event if it was.

This will also need to be updated in Gutenberg in ​https://github.com/WordPress/gutenberg/blob/24b48886eec82287eef3e7b31f2122933f1ad038/packages/block-library/src/categories/index.php#L100

Issue opened: ​https://github.com/WordPress/gutenberg/issues/71788

Test instructions are in the original ticket raised.

After the patch, clicking esc should *not* cause the page to navigate.

[nikunj8866]

Test Report

✅ This report validates that the indicated patch works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/9810

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.28
• Server: nginx/1.29.0
• Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.28)
• Browser: Chrome 141.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-One 2.6
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0
  • Classic Widgets 0.3

Steps to Reproduce

1. Create several post categories and assign them to posts.
2. Install and activate the Classic Widgets plugin (​https://wordpress.org/plugins/classic-widgets/).
3. Add a Categories widget to a sidebar or another widget area, and enable the Display as dropdown option.(​https://prnt.sc/M00ewMxnhx-S)
4. On the frontend, focus on the Categories dropdown using Tab or mouse click.
5. Use the Arrow Down key to highlight another category in the list.
6. 🐞 Press Esc (Escape) to close the dropdown.

Before Patch

• Pressing Esc (Escape) caused the browser to navigate to the selected category archive page instead of closing the dropdown.

Expected Results

• Pressing Esc (Escape) should close the dropdown without triggering navigation to category archive page.
• The previously selected value should remain unchanged.

Actual Results

• ✅ With the patch applied, pressing Esc (Escape) closes the dropdown correctly without redirection.
• Navigation now occurs only when the user confirms a selection (e.g., by pressing Enter or using a mouse click).

Supplemental Artifacts

Before Patch: ​https://screenrec.com/share/OszYSTlP8W
After Patch: ​https://screenrec.com/share/bezgktxXZI

[fakhriaz]

Test Report

Description

❌ Bug not resolved with patch.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/9810

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.29
• Server: nginx/1.29.2
• Database: mysqli (Server: 8.4.6 / Client: mysqlnd 8.2.29)
• Browser: Chrome 141.0.0.0
• OS: Linux
• Theme: Twenty Twenty Five and after Twenty Ten 4.4
• MU Plugins: None activated
• Plugins:
  • Classic Widgets 0.3
  • Test Reports 1.2.0

Actual Results

1. ❌ Bug not resolved with patch.

Additional Notes

• I changed the theme to twenty ten when testing with Classic Widgets

Supplemental Artifacts

Before the patch:
​https://drive.google.com/file/d/1Di9i019RPOpCmNCMd_0rMGx2GvvlGFXs/view?usp=sharing
​https://drive.google.com/file/d/1BsBQgElFCkp4bccAV6AJWh1a7p-qUSFI/view?usp=sharing

After the patch:
​https://drive.google.com/file/d/1QrD55iMgLk7-l92tx8Ynr16S_xBAM1jJ/view?usp=sharing
​https://drive.google.com/file/d/1ycTNST48Im1f5VTJOcnkFajqW3K4-43C/view?usp=sharing

[joedolson]

@fakhriaz Can you tell me what didn't work? Your videos aren't helpful, as they don't tell me what you're doing. I need to know what keys you're pressing to be able to determine anything. Other testers have been successful, and your environment looks effectively identical to the previous test.

[fakhriaz]

@joedolson
What did not work: clicking on escape on the category dropdown menu led to redirection to the category page

My videos show that there was a redirection to the category page after applying the patch

I am using the tab key to navigate to the dropdown category menu > click on enter > use arrow to a category > click escape, as a result there was a redirection to the category menu before and after the patch

A question: should I place the category menu in a specific place?

[joedolson]

This may be specific to Linux; the successful test was on Windows, the failed test on Linux. Hoping that @williampatton will be able to take a look at this on Linux.

I'm not considering this blocking; the helpful impact is still considerable if it fixes issues on Chrome for Windows, as that's a large usage block.

@westonruter Thanks for the reviews! I hadn't considered making significant code style changes here; but the dataset property is new to me, so that seems like a super useful tool.

[joedolson]

Verified behavior with the classic widgets with the updated code.

Both classic Archive and classic Categories widgets don't submit when esc is used to close the form.

I did test after the previous round of changes, but I'll test again.

There is a failing test on Linux; do you have a Linux environment handy to test on? I don't consider it to be blocking, since fixing the Windows behaviors is going to touch a far larger pool of users than Linux, but it would be nice to fix or confirm.

Sorry, I don't have a Linux environment anymore to test on.

Fixed the check whether the widget is a select, which referenced the parent element. With that, I think this is ready.

[joedolson]

Marking for commit. There is the failing check from @fakhriaz, but as the bug fix to Windows behavior will be significantly more substantial than the fix on Linux, I think we can try and address that as a follow up if it's still an issue after the updates from @westonruter.

[joedolson]

In 61104:

Widgets: A11y: Prevent dropdowns from submitting on esc in Windows.

On Chrome and Firefox for Windows, the dropdown format for Category and Archives widgets will submit if the user closes the select element using Escape. Escape should instead cancel the action.

Fix the classic Category and Archives widgets to prevent submission on esc keypresses.

Props adrock42, sabernhardt, whyisjake, westonruter, joedolson, nikunj8866, fakhriaz, mukesh27.
Fixes #63531.

[joedolson]

Reopening to continue to assess on Linux. This patch may not be complete; it resolves the issue for Windows browsers but needs more testing on Linux.

[wildworks]

Since RC1 is about to be released, I'm punting this ticket to 7.0. If you are able to test and improve the patches for Linux, please feel free to proceed.

[joedolson]

I'm leaving this open for 6.9. The only reason it isn't closed is because the current patch hasn't been tested on Linux. If I can get a confirming test on Linux, it'll be closed; otherwise, I'll open a new ticket just to address Linux.

[dhruval04]

Test Report

Description

This report validates whether the indicated patch works as expected.

Patch tested: ​https://github.com/WordPress/wordpress-develop/pull/9810

Tested it on Playground

Environment

• WordPress: 6.9-beta4-61200
• PHP: 7.4.31-dev
• Server: PHP.wasm
• Database: WP_SQLite_Driver (Server: 8.0.38 / Client: 3.40.1)
• Browser: Chrome 142.0.0.0
• OS: Linux
• Theme: Twenty Twenty-Five 1.3
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Actual Results

1. ✅ Issue resolved with patch.

[wildworks]

@dhruval04 Thanks for the testing! Since the issue has been resolved on Linux as well, let's close this ticket.