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 Tab s 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. 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. I didn’t either, until someone filed a bug I couldn’t reproduce until I put my mouse away. Keyboard focus follows tab order.…