Table rendered as two separate table may confuse screen reader users

VolodymyrK

Hi all,
In case if I use table with vertical scroll - the table consist of two separate tables: dataTables_scrollHeadInner and dataTables_scrollBody.
This situation can be seen in next example: https://datatables.net/examples/basic_init/scroll_y.html

When our screen reader users use NVDA "T" key to focus on table - they receive two separate tables instead of one and this situation is confusing for them.

Is there any way to fix this situation?
I tried to use aria-hidden="true" on the first table amt it seems that this solved the problem. At first glance table functionality wasn't affected. But I'm not sure if this is proper way to adress this issue.
Could you recommend any better solution/fix to adress this issue?

allan

The only want to address this is to not use scrollY / scrollX I'm afraid. In my experience internal scrolling elements like that really don't work well with screen readers anyway - a paged table is much better.

DataTables has to split the header, body and footer into separate tables in order to be able to have the header not move when the body is scrolled, and to do so without a scrollbar that covers the header. If we were okay having the scrollbar covering the header, we'd use something like FixedHeader to make the header static and frankly it would make a lot of things a lot easier, but I really don't like that as a UI design.

If you have any other suggestions they would be very welcome.

Regards,
Allan

VolodymyrK

Thanks for the answer Allan.
According to Accessibility guidelines is expected to have table as single entity and as you say it would be a lot easier to have implementation as single table.

What about current implementation I see two main issues:
* Header part is confusing for screen reader users cause they can't see relation between Header and Body parts. Also, this table doesn't have data cells and AXE detect this situations as a violation.
* Body part also has it's own table header which is invisible but anyway can be accessed by screen reader cursor. Hence, when Screen reader user tries to read page using arrow keys - he will traverse Header part first and table headers will be announced. Then he will go to Body part header and read the same headers again.

So, in fact, the table can be correctly announced even without Header part (and perhaps could be hidden from screen readers by aria-hidden="true").
But problem here is that screen reader user can't activate sorting using Body part header.
If Body part headers had same functionality as Header part headers(which could be hidden) it could fix the problem.
But I'm not sure if this approach could be better than approach with single table instead of two.

Best regards

allan

Yup, it is not a easy thing to fix unfortunately. If building for accessibility, I would suggest not using the scrolling ability of the software.

Allan