Single key arrow navigation in theme and media modals can interfere with screen reader navigation

[joedolson]

With a screen reader running, left and right arrow keys are used to navigate. However, in the media and theme modals, they will also trigger moving to the next theme.

There isn't a simple way to prevent this from working only if using a screen reader, so it would be good to provide a way to disable these keyboard events.

This is very close to violating [WCAG SC 2.1.4]​https://www.w3.org/WAI/WCAG21/Understanding/character-key-shortcuts.html, but the criteria is specific to keys that input content, and so it doesn't cover arrow keys.

However, this can be disconcerting for screen reader users, as they may navigate between different items when intending to explore the content.

[joedolson]

The simplest solution is to add a second key as a requirement to trigger arrow navigation. This is fairly standard - that keyboard shortcuts shouldn't be triggered with a single key that has other functions. But it would be a notable change that could impact some people's work flow.

[joedolson]

Ran out of time in 7.0, going to pick this back up for 7.1.

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

## Use of AI Tools

Three changes: use event.originalEvent.repeat instead of event.repeat, update the shortcut documentation in the Help panel, and add missing support for navigating themes in the Customizer. No need to add the spoken message in the customizer, as it is already present in the showDetails method.

A few considerations:

1)
In the Media Library, the usage of event.originalEvent.repeat changes the current behavior. Previously, keeping the arrow keys pressed allowed to navigate attachments very quickly without interruption. Now, the navigation works one attachment at a time, requiring to press Alt + arrow keys multiple times to navigate multiple attachments.

Personally, I liked the previous behavior because it allows a very quick navigation. Now, this is no longer possible. We should make a decision on whether to preserve the 'press and hold' behavior. If so, I think it should be used also in the theme browser, for consistency.

2)
The speak announcements should be debounced.
When clicking multiple times the next and previous buttons or using the keyboard shortcuts multiple times very quickly, users would receive multiple, consecutive, speak announcements at any attachment / theme change. Ideally, the announcement should be triggered when we detect users stop navigating.
If we implement the 'press and hold' behavior from point 1), that would be evrn worse.
Ideally, the announcements should be _debounced_ as in: prevented while the navigation methods are called multiple times within a certain amount of time. If that turns to be difficult to implement, maybe we should try a simple timeout. The announcement should be canceled if users close the modal dialogs within the debounce interval.

3)
The message of the announcement for the themes is slightly different. I would suggest to make them consistent:

• new message: 'themeViewed' => __( 'Viewing theme: %s' ),
• existing string: 'announceThemeDetails' => __( 'Showing details for theme: %s' ),

Ideally, the shorter the better. However, I'm not sure 'Viewing theme' is accurate. Actually, the modal dialogs don't show the theme. They show the theme details.

4)
In the theme browser there's no help to inform users they can use alt / option + the left or right arrow keys or at least I couldn't find any.

5)
If we think Alt + arrow keys is the best option, we should create a new ticket to evaluate whether there are other places in Core and Gutenberg where this pattern should be implemented. This pattern should be consistent everywhere.

1. In all honesty, I never use keyboard navigation in the media library, and wouldn't have even thought of that. But given that change, I think it's better to return to the previous behavior.
2. Agreed.
3. Shorter is better, but only if it's accurate. I'd be fine with shifting both just to 'Theme details: %s'; I feel like the context of 'showing' or 'viewing' can be assumed.
4. I assume you're referring to the screen at Appearance > Themes. The rest of the navigation guidance is in the Overview panel, so I think we could add instructions there.
5. Agreed. I don't know that Alt + arrow is the best option, but I don't have a better idea. It is certainly better than a single-key trigger that's needed elsewhere, however.

I added the debounce, but didn't add a cancellation. I'm not actually sure how to go about doing that.

4\. I assume you're referring to the screen at Appearance > Themes.

Will try to have a look at it tomorrow.

I added the debounce, but didn't add a cancellation. I'm not actually sure how to go about doing that.

I think the cancelation is not needed when using the underscore debounce(). It would be needed when using setTimeout().

I went ahead and changed the debounce() implementation as described in the previous code review.
Testing would be appreciated. HInt for testing purposes: temporarily increase the debounce delay from 500 to 2000.

I think the cancelation is not needed when using the underscore debounce(). It would be needed when using setTimeout().

I stand partially corrected. The underscore.js _.debounce() has an internal ​debounced.cancel method that can be used when needed. It can be called directly on the wrapper function returned by _.debounce() to clear the internal timer, stopping any pending execution. For example: this.announceThemeDebounced.cancel().

We should test the scenario where users may close the modal dialog _before_ the 500ms interval, to avoid an undesired announcement when the modal dialog is already closed. If the announcement is triggered, we should cancel the debounce.

I updated the PR to my best. All the related announcement are now debounced. When closing the modal dialogs, the pending announcement are canceled. This behavior should be tested in the following 4 places:

Installed themes:
/wp-admin/themes.php

Theme installer:
/wp-admin/theme-install.php?browse=popular

Customizer theme preview (click the 'Change' button and then previwe the themes):
/wp-admin/customize.php?return=%2Fwp-admin%2Fthemes.php

Media grid:
/wp-admin/upload.php

Latest commit improves the Help text:

• Adds missing <code> tags.
• Better explains clicking a Theme will open a modal dialog.
• Changes Use the arrow buttons at the top of the dialog... to Use the buttons at the top of the dialog...
• Adds periods at the end of list items, for consistency.

[joedolson]

The current PR not only fixes the targeted problem, but makes significant improvements to screen reader announcements. Marking for commit.

[joedolson]

In 62878:

Accessibility: In modal collections use alt plus arrow for navigation.

The theme browsers and the media attachment browser supported left and right arrow keys to trigger navigation. These interfered with screen reader reading commands, which also use the left and right arrow keys, forcing navigation instead of allowing the screen reader user to read additional content.

Require that the alt key is also pressed to trigger navigation. Also add debounced screen reader announcements to notify users of the new modal context.

Developed in ​https://github.com/WordPress/wordpress-develop/pull/11560

Props joedolson, sukhendu2002, afercia.
Fixes #63760.