ScrollView accessibility issue - focusable items not accessible with keyboard, when using `Shift+Tab` key

[maryananaidenova]

Is there an existing issue for this?

• I have searched the existing issues

Describe the issue

When using Shift+Tab, the ScrollView container became focusable and user is not able to select the focusable items.

Screen.Recording.2026-01-19.at.18.26.06.mov

Expected behavior

Using Shift+Tab should behave as using Tab key - should focus focusable elements in the page content, but backwards

Steps to reproduce

The issue is related with the accessibility and the ability to navigate through page content via keyboard.

1. Place a ScrollView into Modal dialog.
2. When the content of the ScrollView is large enough to become scrollable and there are focusable elements inside of it like buttons, the user is expected to focus each focusable element via hardware keyboard.

Observations:

• when using Tab key, it is working as expected, each focusable element is selected:

Screen.Recording.2026-01-19.at.18.30.05.mov

• when using Shift+Tab, the ScrollView container became focusable instead and user is not able to select the focusable items. ScrollView itself has the accessible={false} and focusable={false} attributes.

Screen.Recording.2026-01-19.at.18.26.06.mov

The issue is reproducible on:

• web, Chrome.
• "react-native-web": "0.20.0",
• "react-native": "0.79.6",

Test case

https://codesandbox.io/p/devbox/amazing-sound-mf2wx7?file=%2Fsrc%2FApp.js%3A67%2C18&workspaceId=ws_BpA2JTLv5X1jcHBMCQ1am6

Additional comments

No response

[sudheer-surest]

@maryananaidenova
I While I was debugging the issue, I tried explicitly setting tabIndex={-1} on the scrollable container to prevent it from being part of the tab order. However, even with tabIndex = -1, the container still receives focus during reverse keyboard navigation.
This led me to further investigate default browser behavior for scrollable regions, and it appears this is influenced by recent Chromium changes.

Browser Behavior Context

According to Chromium’s documentation on focusable scrollers (ref: https://developer.chrome.com/blog/keyboard-focusable-scrollers), starting with Chromium 130, scrollable elements may automatically become focusable under certain conditions—even if manually excluded using tabIndex={-1}.
This browser-level change appears to cause scrollable containers to be treated as fallback focus targets during reverse navigation (Shift + Tab), especially when:

1. The container itself is technically focusable due to overflow behavior
2. The previous element in the navigation order is not focusable
3. The container has scrollable content but no explicitly defined focusable descendants at that boundary

Additional Experiments

To isolate whether this behaviour is specific to ScrollView, I replaced the ScrollView component with a regular View and manually applied overflow: scroll. The result was the same: the browser still focuses the container during reverse focus traversal. This behaviour apparently stems from Chromium’s default focus management for scrollable elements.