recursica-skill-live-regions

Apply the announcement test: new content and new interactive elements are always announced, while purely visual state changes are not. Changes the user did not cause are also announced because the user has no reason to expect them.

Assertive is reserved for errors and conditions the user must know immediately because it interrupts whatever the user is reading. Everything else, including confirmations, result counts, and status updates, uses polite priority which waits for a natural break.

No, a toast always carries its own announcement and nothing else should duplicate it. Whatever statement the toast makes is the announcement, so adding a separate live region would create redundant output.

Every component is responsible for announcing itself, and you must supply what it needs such as accessible names or counts. The application announces only what falls between components, such as a flow that succeeds silently and navigates away.

No, a filtered result count is announced when the filter is applied, not while the user types toward it. Rapid repeated updates should be debounced and coalesced into a single announcement per established accessibility practice.

A component's accessible name, keyboard behavior, and focus management are owned by each component skill, not live region rules. Semantic markup, reading order, and which messaging channel to use are also covered by separate skills.