Browser manufacturers recently changed the default behavior of scrollable elements (which they call "scrollers"). To improve accessibility, these elements are now automatically keyboard focusable (but not click focusable) when the content is larger than the viewport and does not contain any focusable elements.
See: https://developer.chrome.com/blog/keyboard-focusable-scrollers
This introduces additional tab stops that are currently not properly visualized by Scout and may therefore be confusing. It also interferes with existing logic in some of the more complex widgets, e.g. Table, Tree, TileGrid. For example, the '.table' element has an explicit tabindex="0" attribute, but the inner '.table-data' element does not. However, because the '.table-data' is scrollable, the browser now makes the element focusable automatically. But using the arrow keys to scroll the '.table-data' will not work, because the Table widget uses those keystrokes to move the select row and automatically refocuses the '.table' element.
To restore the previous behavior, we automatically add a negative tabindex to all scroll containers. This skips the element during key navigation, but it may still receive the focus programmatically or via a mouse click. Therefore, we use "-2" instead of "-1" (same native behavior) and explicitly exclude it in the custom ':focusable' selector. The FocusContext can therefore detect when such an element receives the focus and can re-position the focus to the nearest focusable parent element.
In future versions, we plan to make scrollable containers focusable again, but it requires additional changes (e.g. proper handling of keystrokes).
Browser manufacturers recently changed the default behavior of scrollable elements (which they call "scrollers"). To improve accessibility, these elements are now automatically keyboard focusable (but not click focusable) when the content is larger than the viewport and does not contain any focusable elements. See: https://developer.chrome.com/blog/keyboard-focusable-scrollers
This introduces additional tab stops that are currently not properly visualized by Scout and may therefore be confusing. It also interferes with existing logic in some of the more complex widgets, e.g. Table, Tree, TileGrid. For example, the '.table' element has an explicit tabindex="0" attribute, but the inner '.table-data' element does not. However, because the '.table-data' is scrollable, the browser now makes the element focusable automatically. But using the arrow keys to scroll the '.table-data' will not work, because the Table widget uses those keystrokes to move the select row and automatically refocuses the '.table' element.
To restore the previous behavior, we automatically add a negative tabindex to all scroll containers. This skips the element during key navigation, but it may still receive the focus programmatically or via a mouse click. Therefore, we use "-2" instead of "-1" (same native behavior) and explicitly exclude it in the custom ':focusable' selector. The FocusContext can therefore detect when such an element receives the focus and can re-position the focus to the nearest focusable parent element.
In future versions, we plan to make scrollable containers focusable again, but it requires additional changes (e.g. proper handling of keystrokes).
381281