[$250] Inner navigation does re-focus Back button

[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: v9.3.55-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: #87292
Email or phone of affected tester (no customers): N/A
Issue reported by: Applause Internal Team
Bug source: Pull Request QA execution
Device used: Windows 11 / Chrome
App Component: Other

Action Performed:

Preconditions: logged in to any account

Steps:

1. Open FAB > Create expense > Manual
2. Enter an amount and press Enter
3. On the confirm page, verify the Back button does NOT have a blue focus ring
4. Press Tab

Expected Result:

Focus moves to the first interactive element (e.g To field) on the confirm page (not the Back button)

Actual Result:

It first focusing to the back button, then to the next interactive element (e.g To 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: @ZhenjaHorbach

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022042166992179290960
• Upwork Job ID: 2042166992179290960
• Last Price Increase: 2026-04-09

[MelvinBot]

Proposal

What is the root cause of that problem?

The useDialogContainerFocus hook (index.ts:67-96) runs after screen transitions in the RHP and calls focusFirstInteractiveElement() on the RHP container. This function queries all focusable elements in DOM order and focuses the first one it finds — which is the Back button, because HeaderWithBackButton renders before MoneyRequestConfirmationList.

The confirmation page (IOURequestStepConfirmation) does not use useAutoFocusInput, so no input claims focus before the fallback runs. Since document.activeElement is still document.body, the guard in focusFirstInteractiveElement passes and the Back button gets silent focus.

Additionally, when navigating via Enter (not keyboard Tab), the first Tab keypress is intercepted to reveal focus on the already-focused Back button rather than advancing — effectively requiring two Tab presses to reach the "To" field.

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

In focusFirstInteractiveElement (index.ts:29-36), skip the Back button when selecting the first focusable element. The Back button can be identified by its native ID (CONST.BACK_BUTTON_NATIVE_ID). The find() call that selects the target element should add a filter to exclude elements with id === CONST.BACK_BUTTON_NATIVE_ID (or the equivalent "back-button" string). This way, focus will land on the first meaningful interactive element (e.g., the "To" field) instead of the navigation chrome.

If no other focusable element exists besides the Back button, it should still fall back to focusing the Back button as a last resort.

What alternative solutions did you explore? (Optional)

• Add useAutoFocusInput to MoneyRequestConfirmationList: This would claim focus on a specific input before focusFirstInteractiveElement runs. However, this is a narrow fix for one page — the same issue could occur on any RHP screen that lacks useAutoFocusInput.
• Set tabIndex={-1} on the Back button: This would remove it from the tab order entirely, which breaks keyboard accessibility for users who need to navigate back via Tab.

Supporting evidence

Data flow:

1. User enters amount and presses Enter → navigation transitions to IOURequestStepConfirmation
2. Header (inside HeaderWithBackButton) calls useDialogContainerFocus via useDialogLabelRegistration
3. After InteractionManager.runAfterInteractions + requestAnimationFrame, focusFirstInteractiveElement(container) runs
4. querySelectorAll finds Back button first in DOM order → it receives silent focus (outline hidden)
5. First Tab press is consumed by the interceptor → re-focuses Back button with visible ring
6. Second Tab press finally advances to the "To" field

Key files:

• src/hooks/useDialogContainerFocus/index.ts — focus management logic
• src/components/HeaderWithBackButton/index.tsx:246-269 — Back button rendering
• src/components/Header.tsx:54-56 — triggers useDialogContainerFocus
• src/pages/iou/request/step/IOURequestStepConfirmation.tsx — confirmation page (no useAutoFocusInput)

Possibly related: #86699 (accessibility focus tracking), #77411 (focus lost returning to previous screen)

---

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.

[melvin-bot]

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

[melvin-bot]

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

[MobileMage]

Proposal

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

When navigating to the confirmation page (e.g. Create expense > Manual > enter amount > Enter), the Back button in the header receives keyboard focus first before the first meaningful interactive element on the page, so pressing Tab once lands on the Back button (with a visible blue ring) instead of going straight to the "To" field.

What is the root cause of that problem?

When a new screen renders, Header calls useDialogContainerFocus, which runs focusFirstInteractiveElement on the dialog container ref. This function queries all elements matching the FOCUSABLE_SELECTOR and picks the first one that isn't aria-hidden or disabled. Because the Back button (role="button", id="backButton") is rendered first in the DOM (inside HeaderWithBackButton, which is above the page body content), it wins as the "first interactive element." The programmatic silent focus is then placed there, and the first Tab keypress re-focuses it visibly before moving on to the real content.

App/src/hooks/useDialogContainerFocus/index.ts

Lines 29 to 34 in 441332c

	function focusFirstInteractiveElement(container: HTMLElement | null): CleanupFn | undefined {
	if (!container || (document.activeElement && document.activeElement !== document.body)) {
	return undefined;
	}
	const targets = container.querySelectorAll<HTMLElement>(FOCUSABLE_SELECTOR);
	const target = Array.from(targets).find((el) => !el.closest('[aria-hidden="true"]') && !el.matches(':disabled') && el.getAttribute('aria-disabled') !== 'true');

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

The focusFirstInteractiveElement function should skip the back button when selecting the focus target. Since the back button already has the well-known id of CONST.BACK_BUTTON_NATIVE_ID ("backButton"), we can exclude it by id in the candidate-selection find. This keeps the fix minimal and targeted without changing the broader focus management system.

App/src/hooks/useDialogContainerFocus/index.ts

Lines 29 to 64 in 441332c

	function focusFirstInteractiveElement(container: HTMLElement | null): CleanupFn | undefined {
	if (!container || (document.activeElement && document.activeElement !== document.body)) {
	return undefined;
	}
	const targets = container.querySelectorAll<HTMLElement>(FOCUSABLE_SELECTOR);
	const target = Array.from(targets).find((el) => !el.closest('[aria-hidden="true"]') && !el.matches(':disabled') && el.getAttribute('aria-disabled') !== 'true');
	if (!target) {
	return undefined;
	}
	let cleanupListener: CleanupFn | undefined;
	if (!hadKeyboardEvent) {
	// On first Tab, prevent default and re-focus the same element with a visible ring
	// so the user sees focus land here instead of advancing past the silent focus.
	const onFirstTab = (e: KeyboardEvent) => {
	if (e.key !== 'Tab' || document.activeElement !== target) {
	return;
	}
	e.preventDefault();
	document.removeEventListener('keydown', onFirstTab, true);
	target.removeAttribute(PROGRAMMATIC_FOCUS_DATA_ATTRIBUTE);
	target.style.removeProperty('outline');
	target.focus({preventScroll: true});
	};
	target.setAttribute(PROGRAMMATIC_FOCUS_DATA_ATTRIBUTE, 'true');
	target.style.setProperty('outline', 'none');
	// No blur cleanup — attributes must survive browser tab-switch blur/re-focus cycles.
	document.addEventListener('keydown', onFirstTab, true);
	cleanupListener = () => {
	document.removeEventListener('keydown', onFirstTab, true);
	target.removeAttribute(PROGRAMMATIC_FOCUS_DATA_ATTRIBUTE);
	target.style.removeProperty('outline');
	};
	}
	target.focus({preventScroll: true});
	return cleanupListener;
	}

// src/hooks/useDialogContainerFocus/index.ts
+import CONST from '@src/CONST';

 function focusFirstInteractiveElement(container: HTMLElement | null): CleanupFn | undefined {
     if (!container || (document.activeElement && document.activeElement !== document.body)) {
         return undefined;
     }
     const targets = container.querySelectorAll<HTMLElement>(FOCUSABLE_SELECTOR);
-    const target = Array.from(targets).find((el) => !el.closest('[aria-hidden="true"]') && !el.matches(':disabled') && el.getAttribute('aria-disabled') !== 'true');
+    const target = Array.from(targets).find(
+        (el) =>
+            !el.closest('[aria-hidden="true"]') &&
+            !el.matches(':disabled') &&
+            el.getAttribute('aria-disabled') !== 'true' &&
+            el.id !== CONST.BACK_BUTTON_NATIVE_ID,
+    );

This ensures that when a new screen mounts and the dialog container focus hook fires, it skips the Back button entirely and silently focuses the first real content element (e.g. the "To" field row). The Tab key then triggers visible focus on that first content element, which is the expected behavior described in the issue.

What alternative solutions did you explore? (Optional)

An alternative would be to add a data-skip-initial-focus attribute to the Back button and check for it in focusFirstInteractiveElement, which would be more generic. However, using CONST.BACK_BUTTON_NATIVE_ID is simpler, already established in the codebase (it is also checked in FormProvider for blur handling), and directly targets the known problematic element without introducing a new convention.

[TaduJR]

Assignment here @amyevans

Thanks!

[TaduJR]

The current expected results violates W3C Guidelines

In discussion here: #87304 (comment)

[abbasifaizan70]

Proposal

What is the root cause of that problem?

This issue happens because the confirmation page clears the currently focused element after navigation, but does not assign focus to any field afterward. On web, when there is no active focus target, pressing Tab moves to the first tabbable element in DOM order.

On the confirmation screen, HeaderWithBackButton is rendered before the list content and its Back button is tabbable, so the first Tab lands on Back first instead of the first form field (for example, To).

App/src/components/MoneyRequestConfirmationList.tsx

Lines 931 to 942 in 441332c

	const focusTimeoutRef = useRef<NodeJS.Timeout | null>(null);
	useFocusEffect(
	useCallback(() => {
	focusTimeoutRef.current = setTimeout(() => {
	// eslint-disable-next-line @typescript-eslint/no-deprecated
	InteractionManager.runAfterInteractions(() => {
	blurActiveElement();
	});
	}, CONST.ANIMATED_TRANSITION);
	return () => focusTimeoutRef.current && clearTimeout(focusTimeoutRef.current);
	}, []),
	);

App/src/components/HeaderWithBackButton/index.tsx

Lines 244 to 269 in 441332c

	{shouldShowBackButton && (
	<Tooltip text={translate('common.back')}>
	<PressableWithoutFeedback
	onPress={() => {
	if (Keyboard.isVisible()) {
	Keyboard.dismiss();
	}
	const topmostReportId = Navigation.getTopmostReportId();
	if (shouldNavigateToTopMostReport && topmostReportId) {
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(topmostReportId));
	} else {
	onBackButtonPress();
	}
	}}
	style={[styles.touchableButtonImage]}
	role={CONST.ROLE.BUTTON}
	accessibilityLabel={translate('common.back')}
	id={CONST.BACK_BUTTON_NATIVE_ID}
	sentryLabel={CONST.SENTRY_LABEL.HEADER.BACK_BUTTON}
	>
	<Icon
	src={icons.BackArrow}
	fill={iconFill ?? theme.icon}
	/>
	</PressableWithoutFeedback>
	</Tooltip>

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

App/src/components/HeaderWithBackButton/types.ts

Lines 112 to 176 in 441332c

	/** Whether we should show a back button */
	shouldShowBackButton?: boolean;
	/** Data to display a step counter in the header */
	stepCounter?: StepCounterParams;
	/** Whether we should show a report avatar */
	shouldShowReportAvatarWithDisplay?: boolean;
	/** Parent report, if provided it will override props.report for AvatarWithDisplay */
	parentReport?: OnyxEntry<Report>;
	/** Report, if we're showing the details for one and using AvatarWithDisplay */
	report?: OnyxEntry<Report>;
	/** Policy tied to the report */
	policy?: OnyxEntry<Policy>;
	/** Single execution function to prevent concurrent navigation actions */
	singleExecution?: <T extends unknown[]>(action: Action<T>) => Action<T>;
	/** Whether we should navigate to report page when the route have a topMostReport */
	shouldNavigateToTopMostReport?: boolean;
	/** Whether the header should use the headline header style */
	shouldUseHeadlineHeader?: boolean;
	/** The fill color for the icon. Can be hex, rgb, rgba, or valid react-native named color such as 'red' or 'blue'. */
	iconFill?: string;
	/** Whether the popover menu should overlay the current view */
	shouldOverlay?: boolean;
	/** Whether we should enable detail page navigation */
	shouldEnableDetailPageNavigation?: boolean;
	/** Number of lines to display for the title */
	numberOfTitleLines?: number;
	/** Whether we should overlay the 3 dots menu */
	shouldOverlayDots?: boolean;
	/** Whether we should display the button that opens the Help Panel */
	shouldDisplayHelpButton?: boolean;
	/** Whether we should display the button that opens new SearchRouter */
	shouldDisplaySearchRouter?: boolean;
	/** 0 - 100 number indicating current progress of the progress bar */
	progressBarPercentage?: number;
	/** Policy avatar to display in the header */
	policyAvatar?: Icon;
	/** Additional styles to add to the component */
	style?: StyleProp<ViewStyle>;
	/** The URL link associated with the attachment's subtitle, if available */
	subTitleLink?: string;
	/** If true, display the individual button instead of the three-dot menu when there's only one menu item */
	shouldMinimizeMenuButton?: boolean;
	/** Whether to open the parent report link in the current tab if possible */
	openParentReportInCurrentTab?: boolean;
	};

/** Whether we should show a back button */
shouldShowBackButton?: boolean;

/** Optional tab index for the back button (web only behavior) */
backButtonTabIndex?: number;

App/src/components/HeaderWithBackButton/index.tsx

Lines 47 to 82 in 441332c

	shouldShowBackButton = true,
	shouldShowBorderBottom = false,
	shouldShowCloseButton = false,
	shouldShowDownloadButton = false,
	isDownloading = false,
	shouldShowRotateButton = false,
	isRotating = false,
	shouldShowPinButton = false,
	shouldSetModalVisibility = true,
	shouldShowThreeDotsButton = false,
	shouldDisableThreeDotsButton = false,
	shouldUseHeadlineHeader = false,
	stepCounter,
	subtitle = '',
	title = '',
	titleColor,
	threeDotsAnchorAlignment = {
	horizontal: CONST.MODAL.ANCHOR_ORIGIN_HORIZONTAL.RIGHT,
	vertical: CONST.MODAL.ANCHOR_ORIGIN_VERTICAL.TOP,
	},
	threeDotsMenuItems = [],
	threeDotsMenuIcon,
	threeDotsMenuIconFill,
	shouldEnableDetailPageNavigation = false,
	children = null,
	shouldOverlayDots = false,
	shouldOverlay = false,
	shouldNavigateToTopMostReport = false,
	shouldDisplayHelpButton = false,
	shouldDisplaySearchRouter = false,
	progressBarPercentage,
	style,
	subTitleLink = '',
	shouldMinimizeMenuButton = false,
	openParentReportInCurrentTab = false,
	}: HeaderWithBackButtonProps) {

shouldShowBackButton = true,
backButtonTabIndex,
shouldShowBorderBottom = false,

App/src/components/HeaderWithBackButton/index.tsx

Lines 246 to 263 in 441332c

	<PressableWithoutFeedback
	onPress={() => {
	if (Keyboard.isVisible()) {
	Keyboard.dismiss();
	}
	const topmostReportId = Navigation.getTopmostReportId();
	if (shouldNavigateToTopMostReport && topmostReportId) {
	Navigation.navigate(ROUTES.REPORT_WITH_ID.getRoute(topmostReportId));
	} else {
	onBackButtonPress();
	}
	}}
	style={[styles.touchableButtonImage]}
	role={CONST.ROLE.BUTTON}
	accessibilityLabel={translate('common.back')}
	id={CONST.BACK_BUTTON_NATIVE_ID}
	sentryLabel={CONST.SENTRY_LABEL.HEADER.BACK_BUTTON}
	>

```ts
<PressableWithoutFeedback
    onPress={() => {
        // ...
    }}
    style={[styles.touchableButtonImage]}
    role={CONST.ROLE.BUTTON}
    accessibilityLabel={translate('common.back')}
    id={CONST.BACK_BUTTON_NATIVE_ID}
    tabIndex={backButtonTabIndex}
    sentryLabel={CONST.SENTRY_LABEL.HEADER.BACK_BUTTON}
>

App/src/pages/iou/request/step/IOURequestStepConfirmation.tsx

Lines 1441 to 1454 in 441332c

	<HeaderWithBackButton
	title={headerTitle}
	subtitle={hasMultipleTransactions ? `${currentTransactionIndex + 1} ${translate('common.of')} ${transactions.length}` : undefined}
	onBackButtonPress={navigateBack}
	>
	{hasMultipleTransactions ? (
	<PrevNextButtons
	isPrevButtonDisabled={currentTransactionIndex === 0}
	isNextButtonDisabled={currentTransactionIndex === transactions.length - 1}
	onNext={showNextTransaction}
	onPrevious={showPreviousTransaction}
	/>
	) : null}
	</HeaderWithBackButton>

<HeaderWithBackButton
    title={headerTitle}
    subtitle={hasMultipleTransactions ? `${currentTransactionIndex + 1} ${translate('common.of')} ${transactions.length}` : undefined}
    onBackButtonPress={navigateBack}
    backButtonTabIndex={-1}
>

This TypeScript change keeps the Back button visible and clickable, but removes it from the tab sequence on the confirmation page so the first Tab lands on the first interactive confirmation field instead.