Customizer: The back button is not keyboard focusable

[wildworks]

The back button in the Customizer has tabindex="-1" applied to it, so it's not keyboard focusable:

​https://github.com/WordPress/wordpress-develop/blob/54e97c4c9a9ad71e6005d7e61e4f011ab08d1d4a/src/wp-includes/class-wp-customize-nav-menus.php#L1148

Therefore, keyboard-only users will have to hit the close button to return to the dashboard before they can access another submenu.

From my testing, it looks like we can remove the tabindex=-1 (and add type="button").

[wildworks]

Customizer Back Button

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

[abcd95]

Thanks @wildworks for raising the issue.

I've submitted a ​PR for the same, please feel free to test the changes.

Here is a screencast of the keyboard navigation for all the sections -

​https://github.com/user-attachments/assets/2e8609ae-8ef5-413a-a49c-bfd40ed676bc

@himanshupathak95
Thanks for the patch! The fix works well, and making the back button keyboard-focusable improves accessibility. 👍

Thanks for the PR!

I think there are a few additional things that need to be addressed to fully address this issue.

• The default value of the type attribute on the button element is submit. We may want to use type="button" to avoid unintended behavior.
• There seem to be other non-focusable back buttons. We may want to investigate where they are used and whether they should be fixed as well:
  • ​class-wp-customize-themes-panel.php
  • ​class-wp-customize-nav-menus.php
  • ​class-wp-customize-widgets.php
• There is JS code that removes the tab index. We may want to investigate whether this can be removed as well (​Source).
• We may also need to modify QUnit tests (​Example):

[joedolson]

I have some memory that there was a reason that the back button was made conditionally non-navigable, but I don't remember the details. I'll follow up and explore.

Thanks, @t-hamano, for the suggestions.

I have updated all the places needed for keyboard navigation. After testing, I found that the JS code change is not necessary since the tabindex attributes are being added directly in the PHP templates. Also, the Qunit tests are not affected either, but I am not sure if we have to update them.

[wildworks]

@abcd95 Sorry, my feedback was not correct.

I tried to find out which changeset this problem occurred in. As a result, I identified that r59224 caused this problem.

It is probably correct that the back button has a initial setting of tabindex="-1". This button should be dynamically applied tabindex="0" via JS code and should be expected to be focusable. However, r59224 seems to have removed the logic.

For example, I found that the following changes could solve this issue by restoring some code. However, simply restoring a single line may not be enough:

diff --git a/src/js/_enqueues/wp/customize/controls.js b/src/js/_enqueues/wp/customize/controls.js
index 7a6e69cf3e..14d3e63d0c 100644
--- a/src/js/_enqueues/wp/customize/controls.js
+++ b/src/js/_enqueues/wp/customize/controls.js
@@ -1615,6 +1615,7 @@
                                } else {
                                        expand = function() {
                                                section._animateChangeExpanded( function() {
+                                                       backBtn.attr( 'tabindex', '0' );
                                                        backBtn.trigger( 'focus' );
                                                        content.css( 'top', '' );
                                                        container.scrollTop( 0 );

@joedolson Could you confirm whether the code removed in r59224 was intentional?