a11y: 'tab' stops scrolling through Table with onRowClick

[Dattaya]

Seems like accessibility is broken in Table and maybe other components (I haven't tried).
First case: it happens if I press 'Shift-Tab' so it moves the scroll bar up as you can see on the next image. After that the last item is the last visible item, because it then switches focus to a button:

Second case if I press 'Up Arrow' key in a way that partially or fully hides focused item:

You can find this table on codepen: http://codepen.io/dattaya/full/evrYqM/

[bvaughn]

This is an unfortunate side-effect of windowing. (There are some others, such as "find in page" browser features won't work in the normal way since content isn't actually on the page.)

I'm not sure how easy this would be to fix, to be honest, nor if it belongs in the base react-virtualized library. (It could make a nice addon though.)

[Dattaya]

Thank you for the explanation, @bvaughn. I don't yet know how this library functions internally so I'm might be saying something stupid but would rendering few more rows that are not visible above and bellow help to resolve this particular issue?

[bvaughn]

That is already possible, actually. By default, react-virtualized renders 10 rows below the threshold. (Check out the overscanRowCount property.)

[Dattaya]

I've just realized that Shift-Tab doesn't work at all unless half of an element is shown even then the behavior is buggy as demonstrated above.

nor if it belongs in the base react-virtualized library (It could make a nice addon though.)

Can this be solved in an add-on or requires changes to the core?

[bvaughn]

I don't know. That sounds like built-in browser behavior, considering the next row(s) are in the DOM just not visible.

[bvaughn]

I see the problem. If you scroll down first, then use Shift+TAB to scroll back, Grid shifts the rows as described here. The result of this though is that there are no rows forward to tab to.

You could work around this by specifying a naive custom overscanIndicesGetter as shown here:
http://codepen.io/bvaughn/pen/oZyZKg

Admittedly this isn't a very satisfying default behavior though. Hm.

[Dattaya]

Thank you, @bvaughn. I've tested your example with a custom overscanIndicesGetter in most of the browsers on my PC (Chrome, Firefox, Edge, IE10-11) and it works fine. In FF one row above and bellow the threshold is not enough for speedy (when you hold the key pressed) scrolling with Tab or Shift-Tab but 2 is sufficient.
However I'm not closing this issue in case you want to make it the default behavior.

[bvaughn]

Thanks for the follow-up info!

I'm going to leave it open for now and give it some more thought. I think maybe I can improve this by default without impacting perf too much.

[bvaughn]

Default behavior has been fixed/corrected via e6656c1. It will go out with the next point release.

[bvaughn]

9.6.0 release just went out with this.