Announcements silently dropped when View is detached or invisible: android.view.View.announceForAccessibility

Answer

View.announceForAccessibility silently drops announcements when the view is detached from the window or not visible. The framework only routes TYPE_ANNOUNCEMENT events from views that are attached and visible, so a transient view that disappears before the event is dispatched will produce no speech.

Supported dispatch patterns

When the target view may be detached or hidden, use one of these approaches:

1. Dispatch a system-level TYPE_ANNOUNCEMENT. Obtain an AccessibilityEvent with TYPE_ANNOUNCEMENT, add the text, and send it through the AccessibilityManager service so the event does not depend on the target view's window attachment. Because the public surface for direct event injection has shifted across releases, confirm the exact method available in your compileSdk before relying on it.
2. Use a persistent live region. Keep a small, always-attached view (for example a TextView in your activity root) with android:accessibilityLiveRegion="polite" and update its text when state changes. The framework announces the change automatically, and the view never detaches.

Interruption and coalescing without confirmation

There is no delivery callback. Screen readers process announcements asynchronously and may interrupt or coalesce rapid messages. Treat announcements as fire-and-forget:

• Debounce or queue transient updates; do not fire multiple announcements within a few hundred milliseconds.
• Keep messages short and infrequent to avoid speech clutter.
• Use AccessibilityManager.interrupt() only for critical, time-sensitive messages, because it stops whatever the user is currently hearing.

Cross-version verification

Because TalkBack behavior and OEM accessibility suites vary, verify on multiple API levels and devices:

1. Enable TalkBack on API 28, 31, and 33+ devices and trigger the announcement while the source view is GONE or detached.
2. Inspect recent event dispatch with adb shell dumpsys accessibility.
3. Test rapid successive announcements to observe the specific screen reader's throttling.

One diagnostic detail would change the recommendation: is the announcement triggered from an Activity/Fragment context where a persistent root view exists, or from a background service where a live region is not available?