In HTML, why is a status message that gets inserted into the page inside a brand-new element carrying aria-live="polite" often announced by nothing at all, and what markup pattern fixes it?

## What a live region is A live region is an element the browser and assistive technology agree to *watch*. You opt in by putting `aria-live="polite"` or `aria-live="assertive"` on the element, or by using a role that implies one — `role="status"` (polite), `role="alert"` (assertive), `role="log"` (polite). From then on, when the content inside that element changes, the screen reader speaks the change without the user having to move focus or the virtual cursor there. The crucial word is *changes*. The live-region machinery is a diff, not a broadcast. Something has to be different from a previous state that the assistive technology already knew about. ## Why the injected-region case is silent The common bug looks completely reasonable: ```html <!-- toast container --> <div id="toasts"></div> ``` ```js // on save success toasts.insertAdjacentHTML('beforeend', '<div role="status">Draft saved</div>'); ``` The element with the live role and the text it should announce enter the accessibility tree in the same mutation. There is no prior content for the new content to differ from — the node is created already "settled". Screen readers register the new live region so that *future* changes inside it will be announced, and say nothing about the text it was born with. Users see a toast slide in and hear nothing. The same failure appears in slower motion in single-page apps: a route renders a `<p role="alert">Login failed</p>` only when the error exists, and it is created and destroyed with the error. Every announcement is a first announcement, which is exactly the case that does not fire. ## The fix: container first, content second Put the empty region in the markup that renders on first paint, and never unmount it: ```html <p id="form-status" role="status" class="visually-hidden"></p> ``` Then the only thing that ever changes is its text: ```js document.getElementById('form-status').textContent = 'Draft saved'; ``` Now there is a genuine before/after inside a node the assistive technology has been watching since page load, and the message is spoken. Clearing the region later (setting it back to an empty string) is harmless — removals are not announced by default. If a framework forces you to create the region dynamically, the workaround is to split the insertion into two steps: append the empty element, yield to the event loop (a `requestAnimationFrame` or a short timeout of roughly 100 ms is the usual figure), then set the text. That gives the assistive technology a chance to notice the region before the content lands. It works, but it is timing-dependent and varies by screen reader — which is why a persistent announcer in the app shell is the pattern that actually holds up. ## Keeping it hidden without breaking it A live region does not have to be visible, but it does have to be **rendered**. Three things silence it completely: - `display: none` and `visibility: hidden` — the element is not in the accessibility tree. - the `hidden` attribute — equivalent to `display: none`. - `aria-hidden="true"` — explicitly removes the subtree from the accessibility tree. A screen-reader-only region uses clipping instead, keeping the element rendered at effectively zero visual size: ```css .visually-hidden { position: absolute; width: 1px; height: 1px; overflow: hidden; clip-path: inset(50%); white-space: nowrap; } ``` A related trap: toggling a visible status message with `hidden` and expecting the un-hiding to announce it. Some screen readers treat the appearance as a change and speak it, others do not. Changing text inside an always-rendered region is the behaviour you can rely on. ## The duplicate-text trap If you write the *same* string into a region twice — two failed logins producing "Password incorrect" — there may be no textual difference to detect, and the second attempt can go unannounced. Fixes in the wild: include something that legitimately varies (an attempt count, a timestamp you keep off-screen), clear the region and set the new text after a tick, or alternate between two regions. Whichever you pick, be aware that "nothing happened" is exactly what the user experiences when the diff is empty. ## What to check when it still does not speak Inspect the accessibility tree in devtools and confirm the region exists there *before* the update, with the live property you expect. Confirm the element is not hidden by any of the three mechanisms above. Confirm you are mutating the *existing* node rather than replacing it — replacing the element with a fresh one is the original bug in disguise. And test with a real screen reader, because the browser devtools will happily show a perfectly configured region that your JavaScript never actually changes in place.