Across a large web application, how would you decide between one shared application-level ARIA live region and per-component live regions, and what breaks in each approach?

## What the choice is really about A live region is a shared audio channel with exactly one listener and no mixer. The architectural question is not "where do I put the div" but "who is responsible for what the user hears over the next ten seconds". Per-component regions distribute that responsibility to everyone, which means nobody has it. ## The case against per-component regions at scale **Lifecycle.** Component-owned regions mount and unmount with their component. The single most common live-region bug is a region created at the same moment as its message, which announces nothing. A region that unmounts while its message is still queued produces the same silence from the other end. Both are structural consequences of tying the region's lifetime to the event's lifetime. **Duplication.** Two teams add a status region for the same underlying event — the save indicator in the toolbar and the save toast — and the user hears everything twice. Nothing in the codebase makes that visible; you only find it by listening. **No rate control.** Ten components that each announce reasonably still add up to an unusable page. Rate limiting only works where the messages converge, and per-component regions never converge. **Inconsistent semantics.** Left to individual judgment, urgency drifts. Assertive gets used for confirmations because someone worried a message was missed, and now the app interrupts constantly. ## The shared-announcer shape The pattern that holds up is a small fixed set of always-mounted regions in the app shell: ```html <div id="a11y-announcer" class="visually-hidden"> <p id="a11y-polite" role="status"></p> <p id="a11y-assertive" role="alert"></p> </div> ``` Rendered once, at the top of the tree, never unmounted, never conditionally rendered. Feature code never touches the DOM; it calls one function that takes a message and an urgency, and that function owns the policy: pick the right region, drop an exact repeat of the last message within a short window, queue rather than overwrite when two messages arrive together, and optionally log every announcement in development so the team can audit the app's soundtrack. That single choke point is the whole benefit. Debouncing, deduplication, rate limiting, and "why did it say that" debugging all become one file's problem instead of forty components' problem. ## What the shared approach costs **Overwrites and queueing.** With one region, a second message arriving before the first has been spoken replaces it, and the first is lost. A minimal queue — write the next message only after a short interval — is not optional at scale. **A single point of failure.** If a layout refactor unmounts the announcer, or a route-level error boundary replaces the shell, the entire application goes silent at once and no test catches it. Guard it: render it above the router, and cover it with a test that asserts the regions exist after navigation. **Awkwardness for isolated contexts.** Widgets embedded in someone else's page, content inside an iframe, or a design-system component intended to work standalone cannot rely on a host-provided singleton. Those need a local region or an injected announcer. **Context loss.** A shared channel carries no implicit context, so every message must be a complete, self-describing sentence. "Saved" is ambiguous when it could have come from any of six panels; "Draft saved" is not. ## Where local regions still win Shared announcers are for transient status. Some live semantics are genuinely local and should stay local: - A chat transcript or activity feed is `role="log"` — append-only, non-atomic, tied to the widget, and meaningless routed through a global status line. - A value readout tied to a control, where `<output>` (implicitly `role="status"`) is the natural element and lives inside the form. - Content in an isolated context that has no access to the shell. The rule I would write down: transient, cross-cutting messages go through the shared announcer; a live region that is intrinsically *part of a component's content* stays with the component. Anything else is a review conversation. ## Making the decision stick A convention nobody enforces decays back to per-component regions within a quarter. What makes it hold: the announcer is the only exported way to announce, direct `aria-live` usage is flagged in review or by a lint rule with a documented escape hatch, the development-mode log makes chattiness visible during normal work, and the accessibility test suite asserts that the shell regions survive routing. Treat total announcement rate as a product-level property with an owner — the same way you treat bundle size — rather than as something each feature decides for itself. ## How I would answer the tradeoff in an interview Default to the shared pair because it eliminates an entire class of bug by construction and because it creates the one place where global policy can live. Accept its costs explicitly — queueing, the single point of failure, embedded contexts — and name the narrow set of cases where a local region is genuinely the right semantics rather than a shortcut.