Why Keyboard Users Can't Scroll Your Overflow Containers | CSS-Tricks

"So, you build a data table with long rows, lots of columns, and horizontal scroll on the container. It works fine with a mouse and you ship it. But! When a keyboard user Tabs into the table, its focus lands on a cell. Then they press the arrow keys to read across the row but nothing happens. They try Tab again, but this time it jumps to the next interactive element entirely outside the table. The rest of the content is there and screen reader users can navigate it just fine, but there is no way to scroll the container without a mouse."

"Keyboard focus follows tab order. The tab order then follows interactive elements, like buttons, links, inputs - basically anything the browser considers actionable. That's the system the spec built for keyboard navigation. Scroll containers are a completely different system because they are layout primitive. What I mean by that is the browser handles overflowing content in different ways any time you set overflow to auto, scroll, or hidden on an element. The browser's job is to manage overflowing content, not necessarily navigate it. The spec never classified overflow as interactive."

"The gap between those two systems is where keyboard users fall through. This is not a browser bug. Every major browser behaves identically here because they are all following the same spec and the scroll container and focus management are both doing their jobs, although they were not designed to work together."

"I didn't either, until someone filed a bug I couldn't reproduce until I put my mouse away. You may have never noticed this because you most likely only test with a mouse. Your screen reader users never noticed because they navigate the accessibility tree, not the scroll container. The only person it traps is the sighted keyboard user and most teams never test for that."

A data table with many columns uses a horizontally scrollable container. Mouse users can scroll normally, but keyboard users who tab into the table land on a cell and then use arrow keys to move across the row without scrolling the container. When they tab again, focus jumps to the next interactive element outside the table, leaving the remaining columns inaccessible by keyboard. Screen reader users can still navigate the accessibility tree, but keyboard-only users cannot operate the scroll container without a mouse. The issue stems from keyboard focus and tab order following interactive elements, while scroll containers are layout primitives managed for overflow rather than navigation. The behavior is consistent across major browsers because it follows the same specification.

Read at CSS-Tricks