[Accessibility]: async select doesn't render aria-results accessibility text when no results found

[kasparsuvi1]

Hey, i think there is issue with async select. As when no options is returned from loadOptions function the ariaLiveMessages.onFilter doesn't get triggered.

Without async loading there is no issue, when no results are found, the correct aria-text gets rendered in html:

When using async loading, also recreatable in offical docs example there will be never rendered 0 results.

reproduction

1. Open asynx example, type "test" to input.
2. id="aria-results" span is empty

Same works on not async example -> id="aria-results" span get children of "0 results available for search term test.".

Other

Also can't overwrite it because ariaLiveMessages.onFilter is not getting called when async loadOptions callback return empty array.

[SeoJaeWan]

Hi, I’d like to work on this if it’s still open.
I was able to reproduce the issue and confirmed it still happens in the current version.
I looked into the code and I think the issue is in LiveRegion.tsx, inside ariaResults:

if (menuIsOpen && options.length && !isLoading && messages.onFilter) {

In a sync Select, options usually contains the full option list, so options.length stays truthy even when the filtered result count is 0.
But in AsyncSelect, options is the result returned from loadOptions, so when the server returns no matches it becomes []. That makes options.length falsy and prevents messages.onFilter from being called, so the "0 results" announcement is skipped.

I think a small fix like this could work:

if (menuIsOpen && (options.length || inputValue) && !isLoading && messages.onFilter) {

This keeps the existing behavior, but also allows the filter announcement to run after the user has typed a search term, even when the async result is empty.

If this direction looks good, I’m happy to open a PR and add a regression test for the async empty-results case.

[kasparsuvi1]

Thanks @SeoJaeWan for looking into it. For me that seems to be right.

My only question is should it also return the message when request to server has not been made. For example the search is only made when inputValue.length() > 3, but i can't think of use case where this would be needed so looks good to me.

[SeoJaeWan]

@kasparsuvi1 That’s a very fair point!

I think the key question is how we want to treat cases where a consumer only triggers async search after a minimum input length (e.g. only searching when inputValue.length > 3).

In those cases, showing "0 results" before a request is actually made could be misleading — so I agree this part needs a clearer expected behavior.

My original suggestion was focused on the confirmed case where an async search has already been performed and returns an empty result, but for the minimum-length / pre-request behavior, I think maintainer guidance would be really helpful here.