[$250] Account - The date picker modal is not announced as "calendar opened"

[applause-bot]

If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!

---

Version Number: 9.3.80-0
Reproducible in staging?: Yes
Reproducible in production?: Yes
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #90448
Email or phone of affected tester (no customers): n/a
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Mac 15.4.1 Safari/Chrome
App Component: User Settings

Action Performed:

Precondition: the VoiceOver is turned on

1. Go to https://staging.new.expensify.com
2. Navigate to Account > Profile
3. Select Date of birth in the Private section.

Expected Result:

The date picker modas should be announced as "calendar opened".

Actual Result:

The date picker modal is not announced as "calendar opened"

Workaround:

Unknown

Platforms:

• Android: App
• Android: mWeb Chrome
• iOS: App
• iOS: mWeb Safari
• iOS: mWeb Chrome
• Windows: Chrome
• MacOS: Chrome Safari

Screenshots/Videos

Bug7161076_1779508932683.111.mp4

View all open jobs on GitHub

Applause Internal Information
Exported by: Rizky Gunawan
Bug ID: 7161076

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022058117265184404393
• Upwork Job ID: 2058117265184404393
• Last Price Increase: 2026-05-23

[applause-bot]

While Applause doesn't embed attachments for this bug, here are the links for quick view:
https://platform.applause.com/services/links/v1/external/e76d89182b5a4f298a196cfbaeb17c47eeb9d2836e2b02a957edeff40c7b64c4

[MelvinBot]

Proposal

What is the root cause of that problem?

The DatePicker component already has an accessibility announcement mechanism via useAccessibilityAnnouncement. When the calendar opens, it creates an aria-live="assertive" wrapper div and injects a role="alert" text node with the "calendar opened" message (index.ts:76-87).

The problem is that on the first calendar open in a session, the aria-live wrapper div is created and populated in the same synchronous DOM operation (index.ts:39-58 called from index.ts:77). VoiceOver on Mac (Safari and Chrome) does not reliably announce content that is added to a newly created aria-live region in the same DOM mutation — the accessibility tree needs at least one rendering frame to "register" the live region before content changes are announced.

Additionally, the announcement root is determined by getAnnouncementRoot(), which checks document.activeElement. Since the text input is blurred before the modal opens, focus falls to document.body, and the function falls back to picking the last [role="dialog"][aria-modal="true"] in DOM order. When the calendar popover's dialog (via react-native-web's ModalContent) hasn't fully registered in the accessibility tree yet, this can cause the announcement to be scoped to the wrong modal context.

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

In useAccessibilityAnnouncement/index.ts, split the wrapper creation and content insertion into two separate frames when the wrapper is newly created. Inside the setTimeout callback at line 76, after getWrapper() returns a newly created wrapper, use requestAnimationFrame to defer the content insertion by one frame, giving VoiceOver time to register the live region before content is added. When the wrapper already exists (reuse path), the current synchronous insertion is fine.

What alternative solutions did you explore? (Optional)

• Pre-creating the aria-live wrapper at app startup: This would ensure the region is always registered, but it couples a UI concern to the app lifecycle and may conflict with the dynamic dialog-scoping logic that moves the wrapper between modal contexts.
• Using AccessibilityInfo.announceForAccessibility on web: React Native Web doesn't support this API on web, which is why the custom DOM-based approach exists.

Investigation details

Announcement flow on web:

1. User clicks date input → showDatePickerModal() blurs the input and sets isModalVisible=true
2. useAccessibilityAnnouncement detects the state change and starts a 300ms timer
3. At 300ms, getWrapper() creates (or reuses) an aria-live="assertive" div inside the topmost dialog
4. A role="alert" div with the message text is appended to the wrapper

Why first-open fails: The module-level wrapper variable (line 25) starts as null. On first open, getWrapper() creates the div and the text is added immediately — same synchronous call stack. VoiceOver doesn't announce because the live region wasn't present in the previous accessibility tree snapshot.

Modal scoping: The calendar popover renders as a fullscreen RN Modal (coverScreen=true via BaseModal.tsx:367), which react-native-web portals to document.body with aria-modal="true" and role="dialog" (when active). The RHP settings panel is also a dialog. The getAnnouncementRoot() function handles this by selecting the last dialog in DOM order.

---

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.

[MobileMage]

🚨 Edited by proposal-police: This proposal was edited at 2026-05-23 09:27:42 UTC.

Proposal

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

With VoiceOver on, navigating to Account > Profile > Date of birth never announces "calendar opened" — because the date picker modal never opens in the first place.

What is the root cause of that problem?

The DOB page renders <DatePicker ... autoFocus />. With autoFocus, DatePicker relies on the text input's onFocus to call showDatePickerModal (see line 157 of DatePicker/index.tsx). But useAutoFocusInput short-circuits when a screen reader is active to avoid hijacking screen-reader navigation:

App/src/hooks/useAutoFocusInput.ts

Lines 57 to 68 in 2fac812

	useEffect(() => {
	if (
	isScreenReaderEnabled ||
	!isScreenTransitionEnded ||
	!isInputInitialized ||
	!inputRef.current ||
	splashScreenState !== CONST.BOOT_SPLASH_STATE.HIDDEN ||
	isPopoverVisible ||
	isInLandscapeMode
	) {
	return;
	}

So with VoiceOver on, the input is never programmatically focused, onFocus → showDatePickerModal never fires, isModalVisible stays false, and the useAccessibilityAnnouncement introduced in PR #90448 never triggers. The PR's QA path tested with VoiceOver off, where auto-focus does open the modal, which is why it passed review but regresses for screen-reader users.

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

In src/components/DatePicker/index.tsx, when autoFocus is true and useAutoFocusInput is going to skip focusing the input (i.e. Accessibility.useScreenReaderStatus() returns true), open the modal directly via showDatePickerModal() once the screen finishes transitioning. We can do this with a useFocusEffect that, gated on autoFocus && isScreenReaderEnabled && !isModalVisible, calls showDatePickerModal() after InteractionManager.runAfterInteractions so popover positioning has settled. This restores the auto-open behavior on single-input DatePicker screens (DOB, IOURequestStepDate, EditReportFieldDate) for screen-reader users, which in turn lets the existing announcement fire as designed.

The relevant call site to fix is here:

App/src/components/DatePicker/index.tsx

Lines 83 to 89 in 2fac812

	const showDatePickerModal = useCallback(() => {
	cancelAutoFocus();
	// Blur the input before showing the modal, so the focus won't be returned after the modal is closed
	textInputRef.current?.blur();
	calculatePopoverPosition();
	setIsModalVisible(true);
	}, [calculatePopoverPosition, cancelAutoFocus]);

What alternative solutions did you explore? (Optional)

N/A

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

PR #90448 wired up useAccessibilityAnnouncement(announcementMessage, isModalVisible, { shouldAnnounceOnNative: true, shouldAnnounceOnWeb: true }) so that "Calendar opened" is dispatched the moment isModalVisible flips to true:

https://github.com/Expensify/App/blob/main/src/components/DatePicker/index.tsx#L44-L46

But the announcement is sent before the calendar UI lands in the accessibility tree, and on top of a focus event that is in the middle of tearing down. Specifically, showDatePickerModal blurs the input and then flips the state in the same tick:

https://github.com/Expensify/App/blob/main/src/components/DatePicker/index.tsx#L83-L89

After textInputRef.current?.blur(), native focus (and document.activeElement on web) falls back to body / no focused element. React then commits isModalVisible = true, the iOS hook fires AccessibilityInfo.announceForAccessibility(...) 100 ms later, and the web hook fires its aria-live insertion 300 ms later. But DatePickerModal doesn't mount CalendarPicker synchronously — PopoverWithMeasuredContent defers content render until anchor measurement completes, and never marks the popover container with accessibilityViewIsModal / role="dialog"+aria-modal="true":

https://github.com/Expensify/App/blob/main/src/components/DatePicker/DatePickerModal.tsx#L67-L91

The net effect on VoiceOver (iOS App + macOS Safari/Chrome — both the affected platforms):

• iOS: announceForAccessibility is fire-and-forget and is scoped to the currently focused AX context. At the 100 ms mark there is no focused context inside the new popover (it isn't accessibility-modal, focus is on the just-blurred input/body), so the utterance is routed to a tearing-down ancestor and silently dropped.
• macOS VoiceOver (web): the web hook's getAnnouncementRoot() searches for the topmost [role="dialog"][aria-modal="true"] and appends an aria-live region inside it (https://github.com/Expensify/App/blob/main/src/hooks/useAccessibilityAnnouncement/index.ts#L27-L37). Because the calendar popover never sets those attributes (shouldDisplayBelowModals is the only modal-related prop), the alert gets appended to the RHP wrapper above it rather than to the calendar's own context, and VoiceOver — which is scoped to whatever it most recently saw activate — doesn't speak it.

TalkBack and NVDA/Narrator don't have this strict focused-context routing, which lines up with the bug only reproducing on the two VoiceOver-based platforms.

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

Instead of layering more delay onto a fire-and-forget announcement, give VoiceOver a proper modal AX scope to attach to and let it announce the calendar via the focus path it already follows for modals. Two small changes:

1. Mark the popover content as an accessibility-modal scope with a name in src/components/DatePicker/DatePickerModal.tsx. RN maps accessibilityViewIsModal to iOS' modal trap and accessibilityRole="dialog" to web's role="dialog" + aria-modal="true" — which is exactly the selector the existing web hook is looking for, and exactly the trait iOS VoiceOver needs to know "I'm in a new modal context":

         shouldSkipRemeasurement
         forwardedFSClass={forwardedFSClass}
         shouldDisplayBelowModals
     >
+        <View
+            accessibilityViewIsModal
+            accessibilityRole="dialog"
+            accessibilityLabel={translate('common.calendarOpened')}
+        >
             <CalendarPicker
                 minDate={minDate}
                 maxDate={maxDate}
                 value={selectedDate}
                 onSelected={handleDateSelection}
                 shouldEnableMonthYearBackdropInNarrowPane={shouldEnableMonthYearBackdropInNarrowPane}
             />
+        </View>
     </PopoverWithMeasuredContent>

2. Move VoiceOver focus into the calendar once it lays out, so the new modal context actually receives focus and is announced. Inside CalendarPicker (the root View), attach an onLayout that runs once, grabs the node handle, and calls AccessibilityInfo.setAccessibilityFocus(reactTag). On iOS this triggers VoiceOver to read the wrapper's accessibilityLabel ("Calendar opened") followed by the focused day. On web, focusing the dialog node (element.focus()) makes macOS VoiceOver enter the dialog and announce its accessible name. This is the canonical iOS HIG pattern for modal presentations and avoids racing against announceForAccessibility entirely.

- AccessibilityInfo.announceForAccessibility(message);
+ const tag = findNodeHandle(calendarRef.current);
+ if (tag != null) {
+     AccessibilityInfo.setAccessibilityFocus(tag);
+ }

(That snippet is illustrative — the actual call lives in a one-shot onLayout inside CalendarPicker, not in the announcement hook.)

3. Remove the redundant upstream call at DatePicker/index.tsx#L45-L46 (or guard it with !isScreenReaderEnabled) once focus-driven announcement is in place, so VoiceOver doesn't get a duplicate "Calendar opened" between the focus event and the manual announceForAccessibility.

Test updates: in tests/unit/components/DatePickerTest.tsx, render the picker, flip isModalVisible, and (a) assert the wrapper around CalendarPicker has accessibilityViewIsModal={true} and accessibilityRole="dialog", (b) mock AccessibilityInfo.setAccessibilityFocus and assert it is called once with the calendar's node handle after first layout.

What alternative solutions did you explore?

1. Bumping DELAY_FOR_ACCESSIBILITY_TREE_SYNC from 100 ms to ~400 ms in the iOS hook (https://github.com/Expensify/App/blob/main/src/hooks/useAccessibilityAnnouncement/index.ios.ts#L27-L30). Rejected — popover measurement time varies with device and layout work, so a fixed delay either fires too early on slow devices or wastes a perceptible chunk of time on fast ones, and it doesn't fix the missing modal AX scope on web. Focus management is deterministic.

2. Switching the iOS path to AccessibilityInfo.announceForAccessibilityWithOptions(message, { queue: true }). This addresses one symptom — utterances being preempted during focus shifts — but does not give VoiceOver anywhere to land afterward: the user hears "Calendar opened" and is then stranded with focus on the blurred input or body, with no path into the calendar grid. The focus-driven approach fixes "what is announced" and "where the user ends up", which matters more for a date picker than for, e.g., a toast.

3. Setting accessibilityHint="Opens calendar" and accessibilityState={{ expanded: isModalVisible }} on the input (https://github.com/Expensify/App/blob/main/src/components/DatePicker/index.tsx#L140-L161). Rejected — accessibilityHint is read on focus, before the modal opens, and the expanded state produces "expanded"/"collapsed" instead of the "Calendar opened" copy in the bug report. Useful as a small additive cue but doesn't satisfy the expected behavior.

Demo

Screen.Recording.2026-05-23.at.14.44.44.mov

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @ZhenjaHorbach (External)

[wildan-m]

Proposal

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

With VoiceOver enabled, opening the date picker on Account > Profile > Date of birth does not announce "calendar opened". The announcement is missing on macOS (Chrome/Safari) and on the iOS app. Note that Android and Windows are not affected — only the two platforms that use VoiceOver.

What is the root cause of that problem?

The "calendar opened" announcement is wired up correctly in the DatePicker. When the modal becomes visible it calls the accessibility-announcement hook:

App/src/components/DatePicker/index.tsx

Lines 45 to 46 in 2fac812

	const announcementMessage = label ? `${label}, ${translate('common.calendarOpened')}` : translate('common.calendarOpened');
	useAccessibilityAnnouncement(announcementMessage, isModalVisible, {shouldAnnounceOnNative: true, shouldAnnounceOnWeb: true});

The problem is in the hook implementations, and it is specific to VoiceOver. That is why only macOS (Chrome/Safari) and iOS are reported, while Android (TalkBack) and Windows (NVDA/Narrator) work — those screen readers don't share VoiceOver's restriction.

Web (macOS VoiceOver). The web hook places the announcement inside a freshly-created aria-live wrapper, and it both creates the wrapper and fills it with the message in the same setTimeout callback:

App/src/hooks/useAccessibilityAnnouncement/index.ts

Lines 76 to 87 in 2fac812

	const timer = setTimeout(() => {
	const container = getWrapper();
	while (container.firstChild) {
	container.removeChild(container.firstChild);
	}
	const node = document.createElement('div');
	node.setAttribute('role', 'alert');
	node.textContent = message;
	container.appendChild(node);
	}, ANNOUNCEMENT_DELAY_MS);

getWrapper() was deliberately moved inside this timeout so the modal's aria-modal="true" DOM is mounted before the wrapper is positioned (this fixed Android web in a prior PR). But VoiceOver on macOS only announces a live region whose content changes after the region already existed in the accessibility tree. A live region that is inserted into the DOM and populated in the same tick is silently ignored — so VoiceOver never speaks the message. TalkBack/NVDA do not have this restriction, which matches the affected-platform list exactly.

iOS (VoiceOver). The iOS hook announces with the non-queued API:

App/src/hooks/useAccessibilityAnnouncement/index.ios.ts

Lines 28 to 30 in 2fac812

	const timeout = setTimeout(() => {
	AccessibilityInfo.announceForAccessibility(message);
	}, DELAY_FOR_ACCESSIBILITY_TREE_SYNC);

When the date picker popover mounts, VoiceOver shifts focus into the new modal and speaks the focused element. Because announceForAccessibility is fire-and-forget with no queueing, that focus-driven utterance preempts and drops the "calendar opened" announcement.

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

Fix each VoiceOver path while preserving the existing Android/Windows behavior:

Web hook (src/hooks/useAccessibilityAnnouncement/index.ts): split the single-tick logic into two phases so the live region exists before its content changes. Inside the setTimeout, first obtain/append the empty aria-live wrapper (keeping it inside the timeout so the modal DOM is already mounted, which preserves the Android fix), then defer writing the message into that wrapper by one more frame using requestAnimationFrame (or a short nested timeout). This guarantees VoiceOver has registered the live region before the text mutation arrives, so the change is announced. Android/Windows are unaffected because their screen readers announce the mutation regardless of ordering.

iOS hook (src/hooks/useAccessibilityAnnouncement/index.ios.ts): replace the non-queued AccessibilityInfo.announceForAccessibility(message) call with AccessibilityInfo.announceForAccessibilityWithOptions(message, {queue: true}). Queueing makes the announcement play after VoiceOver finishes the modal's focus announcement instead of being discarded by it. The existing 100ms tree-sync delay can stay.

No change is needed in DatePicker/index.tsx — the announcement string and trigger are already correct; only the delivery in the two VoiceOver hooks needs fixing.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/91502-voiceover-calendar-announcement?expand=1

What alternative solutions did you explore? (Optional)

For iOS, simply increasing DELAY_FOR_ACCESSIBILITY_TREE_SYNC so the announcement fires after the focus shift was considered, but that is timing-fragile across devices and animation speeds; {queue: true} is the deterministic fix.

For web, mounting a single persistent aria-live region once (e.g. at app root) instead of creating it on demand would also work, but it is a broader change to the shared hook and risks affecting other consumers; the two-phase create-then-populate approach is the minimal, localized fix.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022058117265184404393

[lxyct825-ops]

Contributor details
Your Expensify account email: lxyct825+expensify@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~01174eaf71ab8fc150