How can I announce changing results after someone filters a page?

Announce the outcome of filtering, not a narration of how the filter works. A useful message is a concise count: “12 results” or “No results.” Keep the visible list and its visible count in sync with that message.

For advisory information like a result count, a status role is an appropriate option. It has implicit polite live behavior and atomic announcement behavior, so updated status text can be conveyed without moving focus or interrupting the person’s current activity [S2]. Create the status region when the page is set up, before updating its text; live regions are intended to expose dynamic changes such as results updated without a full reload [S1].

For example, if a category filter leaves 12 items, update the list and its count, then set the status text to “12 results.” If nothing matches, use “No results.” Treat those strings as sample wording, not a required format.

Usually, avoid announcing every intermediate count when choices change rapidly. Instead, let the person move through the choices and announce the resulting count after they make a selection or the update settles. MDN’s dropdown example follows this principle: it updates the live region after the chosen item, rather than announcing every intermediate keyboard selection [S1].

A practical plan is to distinguish exploration from completion. While someone is moving between options, update the results if that is how your page works, but hold the spoken status update. Once a selection is settled, announce the latest count once. If the page updates only after an Apply button, use that action as the point to announce. This is a design approach for reducing chatter, not a guarantee of identical behavior across assistive technologies.

Use a short, complete message that gives the useful outcome. For example:

• “12 results”
• “1 result”
• “No results”

If it helps orient someone, you can include the filter context: “12 results for ‘Open’.” Keep the filter control’s own label separate from the status message, and do not repeat every selected option in a long announcement. A no-results message should describe the outcome plainly; any suggested next step, such as changing a filter, can be visible beside the list.

A worked example, assuming a page has a search field and a category filter: a person types “garden” and chooses “Guides.” When they finish choosing, the list displays 4 matching items and the status text becomes “4 results.” If a later settled change leaves none, the list displays its empty state and the status becomes “No results.”

Copy and adapt this plan:

1. Keep a status region present before filtering changes results.
2. Update the visible list and visible count together.
3. After a selection is settled, set the status to “{count} results,” “1 result,” or “No results.”
4. During rapid movement through choices, do not announce every intermediate count; announce the settled outcome instead.
5. Keep focus on the filter control unless the interaction genuinely requires a focus change. A status message does not itself replace a needed focus change [S2].

Check the experience with the combinations of browser and assistive technology your team supports. Live-region behavior can vary across those combinations [S1], so the source guidance does not establish that every setup will announce every update identically. Adjust based on testing, and make sure the visible result count remains useful even when a spoken update is not heard.