Too-frequent announcements become noise

What it is

Each update can be a fact worth announcing and still, together, choke the speech channel. Announcement flooding is frequency turning notify into noise: progress spoken every 1%, search suggestions on every keystroke, a collaborator’s name on every cursor move, a ticker every second. The user is not deaf to it; they can no longer tell which sentence to act on. The effect is symmetric with no notify at all: once the channel is full, the one critical sentence is flushed too.

Politeness can all be polite and the container small. Flooding asks about count per unit time, not a misplaced attribute.

Why it happens

Speech is a single channel in time. A short sentence costs a second or two; one sentence per second leaves no gap to echo the primary task. Readers merge live mutations only so far: some coalesce short gaps, some speak almost every one. Authors write “be honest about every change”; readers treat every mutation as a candidate; honesty becomes a burst.

The second layer is masking. Queues have a cap; new polite items evict unspoken old polite. Under sustained flood, the occasional error never gets a slot or is knocked off by the next progress tick. Flooding is therefore not merely annoying; it punches through the grading system. An assertive emergency is then just one more sound in the burst. Users respond by turning reader hints to minimum, and even legitimate notify dies — the product wrecked its own channel with rate.

Studying it

Run one task (type in search, watch an upload) at three rates: every event, time-throttled (e.g. at most once per two seconds), boundaries only (start / end / fail). Record primary-task time, missed critical sentences, whether the user turned hints down. Add a cell that injects a real error during the flood and see whether it is reported.

Independent variables: event rate, throttling, boundary-only, politeness. Dependent variables: detection of the critical sentence, task time, whether hint settings were lowered, whether progress drowned the error.

Where it stops holding

A short burst (five related notices in one second) and a long steady flood differ: a burst can be merged into one summary; a steady flood has to change the data source. A refreshable braille display holds few characters; the same rate is less usable on braille than in speech. Users with very high speech rate tolerate more items; defaults must not be designed for them. Games and music already occupy audio; stacking reader bursts fights the soundtrack and needs a product-level mute for dynamic announcements.

Applying it

• For progress, announce start, a milestone (say 50%), and end — not every percent.
• Merge typeahead, character counts, and collaborator cursors on a time window; keep only the latest item inside the window.
• Do not enqueue errors at the tail of the same live queue as the flood; use a separate assertive region that progress is not allowed to write to.
• How to check: run upload or search hard enough to fire a stream, and finish the primary task in headphones. If the operator cannot answer “what percent, did it fail,” or has to mute reader hints, frequency is already noise. Add throttling and rerun; the critical sentence should become paraphrasable again.

Related

• Same group: J5.12.1 Updates that happen without navigation must be announced to AT · J5.12.2 Announcement urgency is graded; non-critical updates must not interrupt · J5.12.3 Transient loading and error feedback is skipped unless it enters a live region
• Nearby: J5.06 Refreshable braille displays · J4.08 Attention and distraction
• Search terms: announcement flooding · live region noise · verbosity