Keyboard / Screen-Reader Accessibility

[cosminnicula]

This is related with #117

It would be great to have the functionality described here http://www.w3.org/WAI/PF/aria-practices/#grid and here http://www.w3.org/WAI/tutorials/tables/ inside the FixedDataTable.

A nice example of an accessible Data Table can be found here http://www.oaa-accessibility.org/examplep/grid2/

[pieterv]

Thanks for bring this up this will be super useful for when taking on accessibility.

cc @jbonta

[cosminnicula]

@pieterv until this will be ready inside FixedDataTable, I'm wondering if it would be feasible to create a wrapper and hack with jQuery the logic for Keyboard / Screen-Reader Accessibility?

For Keyboard, I was thinking to subscribe to the keypress/keydown events at a top level of the DataTable and calculate the position to be focused next based on the data that populates the DataTable, which is after all a matrix. The tricky part here is when you reach the top / bottom of the visible rows and you'll have to handle also scrolling. Also, since the DOM nodes are "recycled", I don't know how the focus would behave.

For Screen-Reader it's even trickier:

• rows: I'll have first to get the "visible" rows, which are the ones that have the "top" position < the height of the table. As soon as the row starts to becomes visible (top < height), I should add proper aria- and role attributes
• header: since the header is more predictable than the rows in the DOM, I should be able to manipulate aria- and role attributes more easily

What do you think, apart from the fact that is a veritable hack? Do you think this approach is reasonable, or maybe one should focus on providing PRs?

[ghost]

Thank you for reporting this issue and appreciate your patience. We've notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.