[Accessibility][Tracking] Dynamic Content Announcements

[rushatgabhane]

Overview

This issue tracks missing announcements for dynamically appearing or updating content such as search suggestions and timer countdowns.

Context

Part of the accessibility improvement effort tracked in https://github.com/Expensify/Expensify/issues/575078

Issues to Fix

• [Due for payment 2026-04-01] SR: Settings - Security: The availability of search suggestions is not announced #74840 - Availability of search suggestions not announced
• [Due for payment 2026-04-01] Screen Reader: Many Pages: The user is not informed about displayed time and when it disappears #77259 - User not informed about displayed timer countdown

Instructions

Suggested Fix: Use live regions (aria-live="polite" / accessibilityLiveRegion) to announce when suggestions appear and when timer content updates.

Note: Discuss on Slack if you are unsure whether a sub-issue should be fixed or if you are unsure about the right fix / expected result. Ideally, create a single PR that will fix all the issues listed to minimize review time (more PRs only if necessary).

Issue Owner

Current Issue Owner: @situchan

[situchan]

@MelvinBot can you post proposal?

[MelvinBot]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Screen reader users are not informed when dynamic content appears or updates on screen. This manifests in two ways:

1. Search suggestions not announced ([Due for payment 2026-04-01] SR: Settings - Security: The availability of search suggestions is not announced #74840): When typing in autocomplete fields (address, pronouns, country, currency, categories, contacts, etc.), suggestions appear visually but the screen reader stays silent. Users have no auditory feedback that results are available or how many there are.

2. Timer countdown not announced ([Due for payment 2026-04-01] Screen Reader: Many Pages: The user is not informed about displayed time and when it disappears #77259): When a magic code countdown timer appears (sign-in, email verification, MFA), it ticks down visually but VoiceOver/TalkBack never announces the time remaining or when it expires. Users don't know they can request a new code.

Both violate WCAG 4.1.3 (Status Messages).

What is the root cause of that problem?

For search suggestions: The key components — BaseSelectionList (src/components/SelectionList/BaseSelectionList.tsx) and BaseAutoCompleteSuggestions (src/components/AutoCompleteSuggestions/BaseAutoCompleteSuggestions.tsx) — render their filtered results in plain View/FlatList/FlashList containers with no accessibilityLiveRegion, no aria-live, and no AccessibilityInfo.announceForAccessibility calls. When the data changes due to user typing, React re-renders the list silently. The SelectionList text input even uses role={CONST.ROLE.PRESENTATION} (src/components/SelectionList/components/TextInput.tsx:124), which strips native semantics from the input, so there is no combobox/aria-expanded pattern either. Every screen listed in #74840 (Address, Pronouns, Country, Currency, Categories, Contacts, etc.) goes through one of these two component trees.

For timer countdown: ValidateCodeCountdown (src/components/ValidateCodeCountdown/index.tsx) updates timeRemaining state every second and renders the time via RenderHTML, but has zero accessibility attributes. The wrapper <View> in each of its three consumers also lacks accessibilityLiveRegion. The only related accessibility code is in the ValidateCodeActionModal parent, which announces the success message after a code is resent — not the countdown itself.

What changes do you think we should make in order to solve the problem?

The fix uses two established codebase patterns: accessibilityLiveRegion (for web/Android) and AccessibilityInfo.announceForAccessibility (for iOS), matching the dual approach used by FormHelpMessage.

1. Search suggestions — announce result availability in BaseSelectionList

Add a visually-hidden <Text> element with accessibilityLiveRegion="polite" inside BaseSelectionList that updates when the filtered result count changes. The text should say something like "X results available" (debounced so it doesn't fire on every keystroke). This covers SelectionList, SelectionListWithSections, and all screens that use them (Pronouns, Country, Currency, Categories, etc.).

For BaseAutoCompleteSuggestions (inline chat suggestions like mentions/emojis), add an accessibilityLiveRegion="polite" on the container Animated.View or a similar hidden status text announcing "X suggestions available" when the suggestions list appears/changes.

Add matching translation keys (e.g., common.resultsAvailable) for the announcement text.

2. Timer countdown — announce start and expiration in ValidateCodeCountdown

Inside ValidateCodeCountdown, add a useEffect that fires AccessibilityInfo.announceForAccessibility at two key moments only:

• When the countdown starts/resets (reaches CONST.REQUEST_CODE_DELAY): announce "Time remaining: 30 seconds"
• When the countdown reaches 0: announce "The time has expired"

Also wrap the RenderHTML output in a <View accessibilityLiveRegion="polite"> so that web/Android screen readers pick up the expiration state change.

This does NOT announce every second (which would be extremely noisy). It only announces the two moments that matter for user awareness.

Add new translation keys validateCodeForm.timeRemainingAnnouncement and validateCodeForm.timeExpiredAnnouncement in all language files.

3. New translation keys

Add the following keys to en.ts (and corresponding translations for other locales):

• common.resultsAvailable (or similar) for search result count announcements
• validateCodeForm.timeRemainingAnnouncement for countdown start
• validateCodeForm.timeExpiredAnnouncement for countdown expiration

What alternative solutions did you explore? (Optional)

• Full combobox ARIA pattern (role="combobox", aria-expanded, aria-autocomplete, aria-activedescendant) on SelectionList inputs: This would be the ideal long-term solution for search inputs, but it's a larger architectural change touching many components. The live region approach is simpler, addresses the WCAG 4.1.3 requirement directly, and can be done in a single PR without refactoring the input/list relationship.

• Announcing every second of the countdown: Rejected because it would be extremely noisy and disruptive for screen reader users. The two-moment approach (start + expiration) provides the essential information without overwhelming the user.

• Using only accessibilityLiveRegion without announceForAccessibility: Would miss iOS VoiceOver announcements in some cases. The dual approach (matching FormHelpMessage pattern) ensures cross-platform coverage.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[situchan]

@MelvinBot implement this

[MelvinBot]

🤖 Draft PR created: #84963
Please mark it as "Ready for review" when it is ready for review.

[melvin-bot]

@situchan Eep! 4 days overdue now. Issues have feelings too...

[situchan]

PR is in review & testing

[melvin-bot]

@situchan Whoops! This issue is 2 days overdue. Let's get this updated quick!