What screen reader users hear when a search returns nothing
A search box sits at the top of nearly every music streaming tool, and for many Australians the fastest way to find a new track is to type the name of a Triple J favourite, an old Hoodoo Gurus B-side, or whatever was just mentioned on a podcast. For a sighted user, an empty result page is easy to interpret: the list is blank, a message may appear, and they start typing something else. For someone navigating purely by sound, the same moment unfolds very differently. Audio cues, ARIA live announcements, and the way focus moves through the page all determine whether a missing result feels confusing or simply informative.
The experience of hitting a dead end matters more than it might first appear. Australian listeners with low vision or blindness often use assistive technology to manage their own playlists while cooking dinner, working in a warehouse in Western Sydney, or unwinding after a long shift. A silent or unclear response from a search field can interrupt that flow, erode trust in the tool, and in some cases mean the person gives up on finding the song at all. Understanding what actually happens in that moment is the first step toward building something kinder.
The silence that follows a press of enter
When a sighted user types a query and presses enter, the page often updates in a flash. They see the same layout, a list, perhaps some album art, but when nothing loads, the area is simply empty. A screen reader user does not get to glance at the page. Instead, the software reads whatever is present in the DOM and any new content announced through live regions. If the application has been built with a polite live region, the user may hear a short line such as "No results found" once the search completes. If no such region exists, the user hears nothing at all, which can be indistinguishable from the application still loading.
This silent gap is one of the biggest sources of confusion reported by Australian screen reader users who post in NVDA and JAWS user groups. A request for a song by The Temper Trap might return nothing because of a typo, but the listener is left wondering whether the queue is still spinning, whether the network has dropped out, or whether the app has frozen entirely. On a flaky NBN connection in regional Queensland, that uncertainty is amplified, because slow responses already make it harder to tell loading from failure.
How live regions handle the empty state
A well-implemented accessible player will use an aria-live attribute set to polite or assertive to push a message to the assistive layer as soon as a search returns. Polite is usually the right choice for search results, because the announcement should not interrupt a track that is still playing in the background. Assertive announcements can be jarring, particularly when someone is listening to a new Tame Impala album from start to finish and just wants to add one more track to the end.
The wording of the announcement itself shapes the experience. A message that simply says "0 results" feels cold and clinical, while something closer to "No matches for Vance Joy in your search" gives the listener enough context to adjust. Some Australian users have asked for the query to be read back alongside the count, since the screen reader may have moved on by the time the live region fires. The difference between a generic and a specific message is small in code but enormous in trust.
Distinguishing a genuine empty state from a loading one
One of the trickier parts of designing search is making it clear when a result is genuinely missing rather than simply on its way. A search that returns nothing for "The Wiggles live at the Sydney Opera House" might mean there is no match in the catalogue, or it might mean the request is still being processed. A polite live region can help by announcing "Searching" at the start of the request and "No results" only once the request has resolved, giving the user two distinct sound signatures for two different moments.
A common bug in many web tools, including some mainstream players, is to clear the result list before the new query has finished. The screen reader then reads an empty list, then later reads the populated list, which can feel like a glitch. In practice, a user in Adelaide who is managing a playlist during their commute has to listen carefully to hear the difference. The simplest fix is to leave the previous results in the live region until new ones are ready, and to clearly distinguish between "no matches found" and "results updated".
Keyboard focus on a blank page
When a search returns nothing, focus usually stays on the search input or moves to a results container. For someone using the keyboard shortcuts for jumping to the fourth track in a queue of 20, the absence of any rows to navigate can be disorienting. A common pattern is to move focus to the empty state message itself, so the user hears the explanation immediately without needing to arrow back through the page.
If the focus is not managed carefully, the user ends up tabbing through headers, navigation menus, and footer links before they realise the search produced nothing. That is a lot of audio to process, especially for someone who also relies on a screen reader to read out their email, calendars, and bus timetables for the 380 route from Bondi. A focused, well-labelled empty state keeps the experience tight and respects the listener's time.
Designing an empty state that actually helps
A good empty state on a search page does more than announce the lack of results. It offers next steps: try a different spelling, browse a category, or return to the previous list. For Australians, this might mean suggesting related artists from the local Triple J Unearthed competition, or pointing toward curated playlists from the ABC. Linking to a broader catalogue can turn a dead end into a discovery moment.
The team behind Queue Music has written about why the player was built for power users, and that thinking shows up in small touches such as offering a keyboard shortcut to clear the search field once it is empty. Sighted users get a clear visual prompt to try again, while screen reader users get an audible nudge and a single key press to start over.
What listeners hear when the queue stays empty
Even with a clear live region, the announcement lands differently depending on context. A user who was expecting a result for Angus and Julia Stone and hears silence will react with frustration, while a user who is browsing for something new may simply shrug and try another spelling. Australian assistive tech users often describe the empty state as a small conversation between them and the tool, and they tend to remember the tools that respond clearly far more than the ones that get the song right.
The medium also matters. A screen reader on a phone, used through the TalkBack interface, may handle aria-live differently than NVDA on a Windows laptop, and the same code can sound fine in one and disappear in the other. For developers supporting Australian users across the country, that means testing on real devices, on the kinds of networks found in regional towns, and with the speech rates many users prefer when they have been listening for hours. An empty state that survives that kind of testing is one that will be quietly appreciated in kitchens, cars, and offices across the country.
Building confidence when nothing plays
Empty results are not failures of the user, they are moments where the tool can step in and be helpful. A short, contextual message, a sensible focus move, and a clear next action all help a screen reader user feel in control of their own queue. For Australian listeners, who often manage their own music during long drives down the Pacific Highway or while working a night shift in a Perth mine, that sense of control matters, and "she'll be right" is not the attitude they bring to their own setup.
When developers treat the empty state as a first-class part of the search experience, the result is a player that feels calm and reliable even when the catalogue comes up short. The next time a search returns nothing, what the listener hears should be just as clear as what a sighted user sees on the screen, and just as easy to act on.