[Due for payment 2026-04-30] Fields do not auto focus

[jponikarchuk]

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.50-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught during regression testing, add the test name, ID and link from BrowserStack: #81378
Email or phone of affected tester (no customers): sjdoisjdojnsodji@gmail.com
Issue reported by: Applause Internal Team
Bug source: Exploratory - Significant User Experience Deterioration
Device used: Mac 26.2 / Chrome
App Component: Money Requests

Action Performed:

1. Go to staging.new.expensify.com
2. Log in with a new Gmail account.
3. Click Skip on work email step.
4. Select something else.
   → Name field does not auto focus.
5. Complete onboarding.
6. Open FAB > Create expense > Manual.
7. Enter amount > Next.
8. On confirm page, click Merchant.
   → Merchant field does not auto focus.

Expected Result:

In Step 4, Name field will auto focus.
In Step 8, Merchant field will auto focus.

Actual Result:

In Step 4, Name field does not auto focus.
In Step 8, Merchant field does not auto focus.

This issue also applies to other fields such as Description field.

Workaround:

Unknown

Platforms:

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

Screenshots/Videos

Video.mp4

View all open jobs on GitHub

Issue Owner

Current Issue Owner: @Ollyws

[melvin-bot]

You have been assigned to this deploy blocker because you recently merged this PR: #81378

[melvin-bot]

💬 A slack conversation has been started in #expensify-open-source

[github-actions]

👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:

1. Identify the pull request that introduced this issue and revert it.
2. Find someone who can quickly fix the issue.
3. Fix the issue yourself.

[OSBotify]

🔍 Investigation Summary

Classification: Frontend bug
Causing PR: #81378 - "fix: Incorrect initial focus when opening the screen" by @daledah (High confidence)
Related Issues: #77370 (original accessibility issue that PR #81378 was fixing)

Recommendation: REVERT

PR #81378 introduced logic to disable autofocus when screen readers are detected, but this is incorrectly affecting web users without screen readers. The autofocus functionality is now broken for normal web users on Chrome/Safari (Mac/Windows), which is the reported symptom.

Labels: Keep DeployBlockerCash (App deploy is blocked). Label correctly applied.

📋 Detailed Analysis

Evidence

PR #81378 was merged on 2026-03-26 and is included in staging deploy 9.3.50-0. The issue is reproducible on staging but NOT on production, confirming this PR introduced the regression.

The PR modified:

• src/hooks/useAutoFocusInput.ts - Added isScreenReaderEnabled check to disable autofocus
• src/components/SelectionList/components/TextInput.tsx - Added isScreenReaderEnabled check
• src/components/SelectionList/index.tsx - Added isScreenReaderEnabled to shouldIgnoreFocus
• src/libs/Accessibility/index.ts - Refactored useScreenReaderStatus to use useSyncExternalStore

Verification

The affected fields mentioned in the bug report both use components modified by PR #81378:

1. Onboarding name field (src/pages/OnboardingPersonalDetails/BaseOnboardingPersonalDetails.tsx:64):

   • Uses useAutoFocusInput() hook which was modified to skip autofocus when isScreenReaderEnabled

2. Merchant field (src/pages/iou/request/step/IOURequestStepMerchant.tsx:53):

   • Uses useAutoFocusInput() hook which was modified to skip autofocus when isScreenReaderEnabled

Both files import and use the modified useAutoFocusInput hook that now checks screen reader status.

Root Cause

PR #81378 was intended to fix an accessibility issue (#77370) where autofocus was incorrectly moving screen reader focus on mobile native apps. However, the implementation appears to have a bug on web platforms:

React Native's AccessibilityInfo.isScreenReaderEnabled() API behaves differently on web compared to native platforms. On web (Chrome/Safari), this API may be:

1. Returning true even when screen readers are NOT active
2. Having timing issues with the initial cached value in useScreenReaderStatus
3. Not properly detecting web screen reader state

The refactored useScreenReaderStatus hook uses a cached value (cachedScreenReaderValue) that defaults to false, but the subscription logic may not be properly initializing it on web, causing it to return incorrect values.

As a result, autofocus is being disabled for all web users, not just those with screen readers active.

[situchan]

Fixed in #84539

[MelvinBot]

Proposal

What is the root cause of that problem?

PR #81378 added isScreenReaderEnabled guards to three auto-focus code paths (useAutoFocusInput.ts, SelectionList/components/TextInput.tsx, SelectionList/index.tsx). When a screen reader is detected, auto-focus is skipped to let the screen reader control focus instead.

The problem is that React Native Web's AccessibilityInfo.isScreenReaderEnabled() is hardcoded to always resolve true (source). There is no browser API to detect screen readers (by design, for privacy), so RNW conservatively assumes one is always active.

This means useScreenReaderStatus() starts as false but immediately flips to true on web and stays there permanently. Every auto-focus check then evaluates if (isScreenReaderEnabled || ...) as true and returns early — focus never happens.

The specific guard in src/hooks/useAutoFocusInput.ts:45:

if (isScreenReaderEnabled || !isScreenTransitionEnded || ...) { return; }

...permanently blocks auto-focus for all ~90 components using this hook on web, not just Merchant and Name fields.

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

Create a web-specific override src/libs/Accessibility/index.web.ts that provides useScreenReaderStatus returning false on web (since there's no reliable way to detect screen readers in browsers). The native file (index.ts / index.native.ts) keeps the current behavior so the screen reader guards still work correctly on iOS/Android where AccessibilityInfo returns accurate values.

Alternatively, the isScreenReaderEnabled guards could be moved behind a platform check (e.g., only apply on native), but a platform-specific file is cleaner and follows existing React Native conventions used elsewhere in the codebase.

What alternative solutions did you explore? (Optional)

1. Patch react-native-web — too invasive and would be lost on upgrades.
2. Remove the isScreenReaderEnabled guards entirely — would regress the accessibility fix from PR fix: Incorrect initial focus when opening the screen #81378 on native platforms.
3. Use Platform.OS checks inline at each call site — would work but is more scattered and harder to maintain than a single platform-specific file.

---

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.