[$75] Keyboard Navigation: Landing Page: The combobox of Language is not focusable with Tab key

[nbhardwaj-del]

Action Performed

1. Using any desktop browser, open the web page https://new.expensify.com/
2. Press Tab key and try to focus the language selection combo box, located under the 'Get Started' section

Expected Result

The control should be focusable with Tab key.

Actual Result

When users use keyboard navigation to reach the language combo box using the TAB key, the language selection is not focusable at all. Focus moves from 'Log in' to the 'phone or email' input field, skipping the language selection completely.

HTML:
DeutschEnglishEspañolFrançaisItalianoNederlandsPolskiPortuguês (BR)中文 (简体)日本語

Area issue was found

Landing Page

Failed Checkpoint

WCAG 2.1.1 Keyboard
https://www.w3.org/WAI/WCAG22/Understanding/keyboard

User Impact

People who are blind cannot use pointing devices like a mouse that require eye-hand coordination. People with low vision may have trouble finding or tracking a pointer indicator on screen. Some people with hand tremors find using a mouse very difficult and therefore usually use a keyboard.

Suggested Resolution

Remove the currently used tabindex="-1", so the control becomes focusable with a keyboard.
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Global_attributes/tabindex

Environment(s)

Windows Windows 10 - Chrome

Bug6985836_1761579948366.Language_selection_not_keyboard_accessible.mp4

Version Number: NA
Reproducible in staging?: NA
Reproducible in production?: NA
Email or phone of affected tester (no customers): NA
Logs: https://stackoverflow.com/c/expensify/questions/4856 NA
Notes/Photos/Videos: Any additional supporting documentation Yes
Expensify/Expensify Issue URL: https://platform.applause.com/products/36605/community-issues/6985836
Issue reported by: NA
Slack conversation: NA

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022009685699448221502
• Upwork Job ID: 2009685699448221502
• Last Price Increase: 2026-01-09

Issue Owner

Current Issue Owner: @mallenexpensify

[melvin-bot]

📣 @nbhardwaj-del! 📣
Please report bugs or suggest features in the #expensify-open-source Slack channel, don't directly open issues in this repo!
Instructions here to join the channel 📖

[TaduJR]

Proposal

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

On the landing page (https://new.expensify.com/), when users navigate using the keyboard Tab key, the language selection combobox is completely skipped and not focusable. Focus moves directly from the "Log in" button to the "phone or email" input field, making the language selector inaccessible to keyboard-only users (people who are blind, have low vision, or have mobility impairments preventing mouse use).

This violates WCAG 2.1.1 Keyboard accessibility guidelines, which require all functionality to be accessible via keyboard.

What is the root cause of that problem?

The root cause is in the BasePicker component where tabIndex: -1 is hardcoded in the pickerProps object, removing ALL pickers from the keyboard tab order across the entire application.

Code location:

App/src/components/Picker/BasePicker.tsx

Line 209 in 5dc4f0c

tabIndex: -1,

pickerProps={{
    ref: picker,
    tabIndex: -1,  // ❌ This removes the picker from keyboard navigation
    onFocus: enableHighlight,
    // ... rest of props
}}

Historical Context

The tabIndex: -1 was added in September 2023 via PR #26846 to fix issue #25759:

• Original Problem: On iOS mobile web Chrome, when users focused an input field and pressed the soft keyboard's down arrow button, it would unexpectedly navigate to the language picker at the bottom of the page
• Solution Implemented: Added tabIndex: -1 to prevent picker from being in tab order
• Unintended Side Effect: This broke desktop keyboard accessibility for ALL users on ALL platforms

Commit that introduced the issue:
83e904d

Original PR:
#26846

Original Issue:
#25759

The Core Problem

The fix was too broad - it applied tabIndex: -1 to ALL pickers on ALL platforms, when the original issue only affected mobile soft keyboard navigation. Desktop keyboard Tab navigation and mobile soft keyboard arrows are two completely different input methods that should be handled separately.

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

Implement platform-specific tabIndex that differentiates between mobile and desktop:

• Desktop: Use tabIndex: 0 to allow keyboard Tab navigation (fixes WCAG violation)
• Mobile: Use tabIndex: -1 to prevent soft keyboard arrow navigation issues (preserves original fix)

Implementation

File: src/components/Picker/BasePicker.tsx

Location of changes:

App/src/components/Picker/BasePicker.tsx

Lines 42 to 70 in 5dc4f0c

	const theme = useTheme();
	const styles = useThemeStyles();
	const [isHighlighted, setIsHighlighted] = useState(false);
	// reference to the root View
	const root = useRef<View>(null);
	// reference to @react-native-picker/picker
	const picker = useRef<RNPickerSelect>(null);
	useEffect(() => {
	if (!!value || !items || items.length !== 1 || !onInputChange) {
	return;
	}
	// When there is only 1 element in the selector, we do the user a favor and automatically select it for them
	// so they don't have to spend extra time selecting the only possible value.
	const item = items.at(0);
	if (item) {
	onInputChange(item.value, 0);
	}
	// eslint-disable-next-line react-compiler/react-compiler, react-hooks/exhaustive-deps
	}, [items]);
	const context = useScrollContext();
	/**

Change 1: Add platform-specific tabIndex logic

After line 52 (after const styles = useThemeStyles();), add:

/**
 * Determine if the picker should be removed from the tab order.
 * On mobile, we use tabIndex=-1 to prevent soft keyboard navigation arrows from jumping to the picker.
 * On desktop, we use tabIndex=0 to allow keyboard Tab navigation for accessibility (WCAG 2.1.1).
 *
 * Related issues:
 * - #25759: Mobile soft keyboard navigation issue (fixed by tabIndex=-1 on mobile)
 * - #74746: Desktop keyboard accessibility issue (fixed by tabIndex=0 on desktop)
 */
const pickerTabIndex = useMemo(() => {
    const os = getOperatingSystem();
    const isMobile = os === CONST.OS.IOS || os === CONST.OS.ANDROID;
    // On mobile: Remove from tab order to prevent soft keyboard navigation issues
    // On desktop: Keep in natural tab order for keyboard accessibility
    return isMobile ? -1 : 0;
}, []);

Change 2: Use the dynamic tabIndex value

Location:

App/src/components/Picker/BasePicker.tsx

Line 209 in 5dc4f0c

tabIndex: -1,

Replace line 209:

tabIndex: -1,

With:

tabIndex: pickerTabIndex,

Complete Code Changes

diff --git a/src/components/Picker/BasePicker.tsx b/src/components/Picker/BasePicker.tsx
index lodashDefer from 'lodash/defer';
@@ -42,6 +42,20 @@ function BasePicker<TPickerValue>({
     const theme = useTheme();
     const styles = useThemeStyles();

+    /**
+     * Determine if the picker should be removed from the tab order.
+     * On mobile, we use tabIndex=-1 to prevent soft keyboard navigation arrows from jumping to the picker.
+     * On desktop, we use tabIndex=0 to allow keyboard Tab navigation for accessibility (WCAG 2.1.1).
+     *
+     * Related issues:
+     * - #25759: Mobile soft keyboard navigation issue (fixed by tabIndex=-1 on mobile)
+     * - #74746: Desktop keyboard accessibility issue (fixed by tabIndex=0 on desktop)
+     */
+    const pickerTabIndex = useMemo(() => {
+        const os = getOperatingSystem();
+        const isMobile = os === CONST.OS.IOS || os === CONST.OS.ANDROID;
+        return isMobile ? -1 : 0;
+    }, []);
+
     const [isHighlighted, setIsHighlighted] = useState(false);

     // reference to the root View
@@ -206,7 +220,7 @@ function BasePicker<TPickerValue>({
                 }}
                 pickerProps={{
                     ref: picker,
-                    tabIndex: -1,
+                    tabIndex: pickerTabIndex,
                     onFocus: enableHighlight,
                     onBlur: () => {
                         disableHighlight();

Why This Solution Works

1. Fixes Current Issue ([$75] Keyboard Navigation: Landing Page: The combobox of Language is not focusable with Tab key #74746): Desktop users can now Tab to the language picker, meeting WCAG 2.1.1 requirements
2. Preserves Original Fix ([PAID] [$1000] iOS- mWeb Chrome redirects to bottom and focus language option #25759): Mobile soft keyboard arrows still won't navigate to picker unexpectedly
3. Platform-Appropriate: Each platform gets the behavior it needs without side effects
4. Uses Existing Infrastructure: Leverages the already-imported getOperatingSystem() utility and CONST.OS values
5. Well-Documented: Clear comments explain why different platforms need different behavior
6. Minimal Risk: Only affects the specific problematic behavior on each platform
7. No New Dependencies: Uses existing imports already present in the file

[TaduJR]

Let me know if test-branch or demo needed.

[Eskalifer1]

Proposal

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

Keyboard Navigation: Landing Page: The combobox of Language is not focusable with Tab key

What is the root cause of that problem?

Currently, we have set tabIndex: -1, which prevents focusing on both mobile and desktop devices:

App/src/components/Picker/BasePicker.tsx

Line 209 in 1e2c61e

tabIndex: -1,

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

We need to make this parameter dynamic (by default, we can give it a value of -1), and then pass it from the parent component here as 0:

App/src/components/Picker/index.tsx

Lines 5 to 32 in 1e2c61e

	function Picker<TPickerValue>({ref, ...props}: BasePickerProps<TPickerValue>) {
	const additionalPickerEvents = (onMouseDown: OnMouseDown, onChange: OnChange<TPickerValue>): AdditionalPickerEvents => ({
	onMouseDown,
	onChange: (e) => {
	if (e.target.selectedIndex === undefined) {
	return;
	}
	const index = e.target.selectedIndex;
	const value = e.target.options[index].value;
	onChange(value as TPickerValue, index);
	},
	});
	return (
	<BasePicker<TPickerValue>
	// eslint-disable-next-line react/jsx-props-no-spreading
	{...props}
	// Forward the ref to Picker, as we implement imperative methods there
	ref={ref}
	// On the Web, focusing the inner picker improves the accessibility,
	// but doesn't open the picker (which we don't want), like it does on
	// Native.
	shouldFocusPicker
	key={props.inputID}
	additionalPickerEvents={additionalPickerEvents}
	/>
	);
	}

But that's not all, because now select is focused but not pressed when Enter is pressed. To fix this, we can add a new callback to additionalPickerEvents so that it only works on non-native devices:

        onKeyDown: (e: React.KeyboardEvent<HTMLSelectElement>) => {
            if (e.key === 'Enter' || e.key === ' ') {
                e.preventDefault();
                const select = e.currentTarget as HTMLSelectElement;
                if (typeof select.showPicker === 'function') {
                    select.showPicker();
                } else {
                    select.click();
                }
            }
        },

PS: This approach can be changed if the team decides that we can use a different approach.

PS2: We can make the tab focus logic dynamic (depending on a specific parameter (e.g., shouldFocusOnTabKey) if it is not needed in all places).

We should additionally pass aria-label to fix other issue(#74855)

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

[melvin-bot]

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

[mallenexpensify]

Accessibility, addressing as part of a project.