Customizer Menus: Accessibility: improve search for menu items

[designsimply]

/hat tip @afercia for the original report at ​https://github.com/voldemortensen/menu-customizer/issues/89

When adding new links, you can search existing links in the "Search Menu Items". In its current form this search is barely usable for screen reader users. A couple of things could improve the experience:

1. the "search as you type" script should try to detect when users actually end typing and debounce the search, see for example what was done in core for the Themes search: https://core.trac.wordpress.org/ticket/26600
2. the search results (or no results) should be announced to assistive technologies, possible use case for wp.a11y.speak see same core ticket 26600
3. a short description of the "live" search functionality could help, see the Themes search in core, i.e.: aria-describedby="live-search-desc"

[designsimply]

Related: #32710

[afercia]

I'd say also to consider to increase the "wait" interval from the current 250ms to 500ms, looking at other implementations in core the most used setting is 500ms. For example:

• themes search: 500ms
• wplink (with setTimeout): 500ms
• tags autocomplete ()inline-edit-post.js and tags-box.js): 500ms

Though 500ms is still an assumption and there are several motor disabilities that don't allow to type so fast, it's for sure better than 250ms.

[afercia]

First pass:

• add a description and an aria-describedby attribute to inform users this is a "live" search
• add some wp.a11y.speak messages to announce the number of search results, as done for Themes see #26600
• use aria-busy to stop screen readers announcing content while the "loading more results" is running
• increase the search debounce wait interval to 500ms
• fix a small bug where the message dispatched to wp.a11y.speak may be an undefined variable

See in the screenshot below the new messages logged in the console when searching for (in order):

• "markup"
• "mark"
• "ma"
• and then when scrolling or tabbing through the results

[celloexpressions]

This looks good, other than increasing the debounce to 500ms. I'm fine with results loading before they finish typing or if they pause slightly, in fact, I think that's useful. In a lot of cases they'll find what they're looking for before needing to type out the full phrase. Working with it currently, it seems a bit slow to load results, and adding an extra 250ms before even starting the ajax call will only make it feel slower. We're not loading a lot of data here, so I don't see an issue with a few extra ajax calls from a usability perspective. The code should be preventing itself from displaying results (and therefore announcing any results for screenreaders) if more typing or another search was initiated since the returned one was sent; if that's no longer working we can simply fix that rather than increasing the debounce for all users.

[ocean90]

In 32891:

Customizer: Accessibility improvements for menu item searches.

• Add a description and an aria-describedby attribute to inform users this is a "live" search.
• Announce the number of search results via wp.a11y.speak.
• Use aria-busy attribute to stop screen readers announcing content while the "loading more results" is running.
• Increase the search debounce wait interval to 500ms to be consistent with other live searches.
• If a search fails don't call wp.a11y.speak with an undefined variable.

props afercia.
see #32720.

[GaryJ]

Replying to afercia:

looking at other implementations in core the most used setting is 500ms.

Probably worth a new ticket to make this a constant that can be consistently used?

[afercia]

@celloexpressions: I admit 500ms is just an assumption as well as 250ms. Shouldn't be based on personal feeling but on some real data. I'd say a user setting would probably make sense here since users have very different needs and very different typing speeds. Not to mention users who use alternative device inputs, usually very slow. Operating systems have some kind of "repeat rate" setting and I think WordPress should have something similar especially if it's going to use this kind of interaction more and more in the future.

@GaryJ
Yup, as I see it all WP components that have a "something magic happens while you type" feature should use the same interval value. Maybe #31818 ? Or feel free to open a new ticket. Maybe propose a new user setting? With typing speed auto-detection. Just type something here and we will take care of this thing for you :)

[afercia]

Changing from "enhancement" to "bug" as agreed with @obenland.

[ocean90]

@afercia What is missing to get this ticket closed?

[afercia]

Replying to ocean90:

@afercia What is missing to get this ticket closed?

Nothing as far as I can see. Feel free to reopen if I'm missing something.