Can screen-reader users tell when filtered results have changed?
A catalogue can replace its cards after a filter is selected while leaving a screen-reader user unsure whether anything happened. The decision is how to communicate completion, not how to read the entire list aloud. We will use a hypothetical materials catalogue and a “three results found” message to define a practical review. This is not an accessibility audit of a client site. The cover is a conceptual illustration of a quiet change notification.
1. Distinguish the result list from its status
Imagine an outdoor-material filter reducing six products to three. The cards are the result content; “3 products found” is the short status. W3C’s explanation distinguishes these and describes short result or waiting messages that update without focus as information assistive technology should be able to identify. Include loading, completed and empty states in the design file, not only the finished card grid. A spinner alone is not a complete feedback plan. Prepare concise messages using terminology that makes sense to the catalogue’s customers.
2. Use a quiet announcement for ordinary completion
MDN describes the status role as providing an implicit polite live region. The technical team can update a short result message in an appropriate status area without moving keyboard focus to it. That does not mean making the whole catalogue a live region. Reading every card in sequence can obstruct the person’s task. Aim to acknowledge that the choice was applied, then let the visitor explore the products in their own order. The announcement should support navigation rather than become another interruption to manage.
3. Do not announce an outdated request
Imagine the visitor choosing wood and immediately switching to metal. If the first request finishes later, it should not replace the current results or announce the wrong count. Add this case to acceptance checks: the active selection, visible cards and spoken count must describe the same request. Announce a meaningful completed change rather than producing a new message for every small keyboard movement. Try a slow connection and review both the waiting state and completion. An obsolete message left visible can mislead users as well.
4. Test focus and the empty state together
After selecting a filter with the keyboard, confirm that focus remains usable and the next control can be reached. If nothing matches, show a clear empty-result message and a way to clear filters. A person hearing the short announcement should be able to reach that action through ordinary navigation. Reading the whole page again or opening an unexpected dialog may be unnecessary. Test with an actual screen-reader and browser combination; finding a role in HTML alone does not establish that the experience works correctly.
5. Finish with a small customer task
Use a task such as: “Choose outdoor materials, find out how many results remain, then clear the selection.” Compare the visible count, spoken message, keyboard focus and displayed cards in one record. Note the device, browser, screen reader and date, and avoid claiming results for untested environments. Include this check in web design delivery alongside the catalogue filter guide. The empty search results guide addresses what to offer when nothing matches. A short status message complements a clear catalogue structure; it does not replace one.
Frequently asked questions
Should the whole product list be a live region?
Usually the short status is kept separate. Test the actual screen-reader experience and avoid unnecessary long announcements.
Is adding a status role enough?
No. Verify timing, accuracy, visible feedback and focus in real use as well.