A search page writes its result count into an aria-live="polite" region on every keystroke, and screen-reader users report a constant stream of speech they cannot get past. How do you diagnose and fix the noise?

## Reading the symptom correctly "Constant stream of speech" almost never means the live region is configured wrong. It means it is configured right and being fed too often. A live region announces every content change, and an as-you-type search produces one change per keystroke plus one per response. Ten characters typed can generate twenty announcements, each queued politely behind the last, so the user hears stale counts for seconds after they stopped typing and cannot hear the characters they are entering. ## Diagnosis Work through it in this order: 1. **Count the writes.** Instrument or log every write to the region. If the count tracks keystrokes, that is the whole story. 2. **Count the regions.** Search the rendered page for `aria-live`, `role="status"`, `role="alert"` and `role="log"`. A common cause of doubled speech is two regions describing the same event — a status line with the count and an alert for the empty state, both firing on the same search. 3. **Check for nesting.** A live region inside another live region can announce a change twice. Regions should be leaf containers you own, not wrappers around large parts of the page. 4. **Check the region's size.** If someone put `aria-live` on the results container itself, every re-render re-announces rows. The announcement belongs on a small status element, not on the data. 5. **Listen.** Devtools will show a well-formed region with the right attributes and tell you nothing about how it sounds. Run the real flow with a screen reader. ## The fixes, in order of impact **Announce settled state, not keystrokes.** Debounce the announcement — typically a few hundred milliseconds after the user stops typing, or when the request resolves, whichever is later — and announce once. Intermediate counts have no value to anyone; nobody needs to hear "412 results, 88 results, 13 results". **Write one complete sentence.** Put the whole message in the region rather than wiring a number into surrounding static text. "13 results for laptop" stands alone; a bare "13" does not. Because `role="status"` implies `aria-atomic="true"`, a single sentence in a single region is announced cleanly as one unit. **Stay polite.** The instinct when messages seem to be missed is to escalate to `assertive`. That converts a queue problem into an interruption problem: the user is now cut off mid-word on every search. Assertive is for things like an expiring session, not for result counts. **Use aria-busy for staged updates.** If the results DOM is emptied, refilled and then counted, set `aria-busy="true"` on the region before the sequence and `false` after, so the intermediate states are not each announced. Clear it on the error path too — a region left busy never announces again. **Collapse duplicates.** Route all search-status messages through one announcer so "no results" and "13 results" cannot both fire. If two states are mutually exclusive, they belong in the same region. ```html <label for="q">Search products</label> <input id="q" type="search" autocomplete="off"> <p id="search-status" role="status" class="visually-hidden"></p> <ul id="results"></ul> ``` The input, the status and the results are three separate things: only the status element is live. ## Judging what deserves an announcement at all Not every state change is worth speech. A useful filter: would you show a sighted user a toast for this? If not, it probably does not need announcing either. Result counts after a *deliberate* search, submission outcomes, and asynchronous completions that the user is waiting on are worth it. Hover states, incremental filtering while typing, progress ticks and background refreshes are usually not, or are worth one summary message at the end. There is also a floor: announcing too rarely is its own bug. If a user searches and hears nothing, they cannot tell whether the page is thinking, broken, or empty. "No results for laptop" is essential; it is the twenty announcements before it that are not. ## The duplicate-message subtlety With a debounce in place you may hit the opposite trap: two consecutive searches that legitimately return the same count write the identical string, and some screen readers, seeing no textual difference, say nothing. If that matters for your flow, include something that varies naturally — the query text itself usually does the job, which is another argument for full sentences over bare numbers. ## What good looks like One small, always-present, visually hidden `role="status"` region per view. One code path that writes to it. Messages that are complete sentences. A debounce between user input and announcement. `aria-busy` around genuinely staged updates. No assertive regions unless something is on fire. Verified by listening, not by reading the DOM.