Bug: Hidden footer cell copies tabindex

sebastianbarth

Hi Allan,

in datatables.mjs ( 2.1.8 ), when copying the header, you avoid copying the tabindex. You don't do so for the footer after, which allows setting focus on the hidden footer cell as well.

    headerCopy = header.clone().prependTo( table );
    headerCopy.find('th, td').removeAttr('tabindex');
    headerCopy.find('[id]').removeAttr('id');

    if ( footer ) {
        footerCopy = footer.clone().prependTo( table );
        footerCopy.find('[id]').removeAttr('id');
    }

sebastianbarth

I am currently implementing WAI Aria grid pattern for the table, which rules that there must be exactly one tabstop (element with el.tabindex >= 0) at any time in the grid container. AFAIK, for tables there is not a single ARIA role that would permit cells to be focussable except of the grid role.

Datatables breaks with this by assigning a tabindex to column headers which are sortable.

How can I avoid headers to get a tabindex assigned at all?

allan

How can I avoid headers to get a tabindex assigned at all?

It should be that you set tabIndex to -1, but there is an error in the current code in that the parameter isn't used there! I will fix that.

The idea of assigning a tab index was that the headers should be accessible by keyboard using the tab and then hit return to sort. How else would they be accessible by keyboard?

Allan

sebastianbarth

The ARIA grid pattern describes that the cell must navigable to using keyboard input. If cell is not the only tabbable cell, than after tabbing to the only tabbable cell, the user must navigate via other keys, like arrow keys to the cell. If the cell contains only one tabbable (our case) we would directly focus this tabbable. If more elements are there, the cell is focused instead and with F2 or Enter the user is able to enter the cell.

We consulted professional accessibility expert about this topic: ARIA grid and treegrid are apparently the only data table patterns that would be applicable for an interactive table. Sorting counts as interaction here.

allan

I've committed a fix for the error whereby tabIndex was being ignored. It will be in the nightly build shortly and in the next release - apologies for that error.

It sounds like a lot of work rather than simply allowing the browser to do the tab flow, but I do get it for cases when you don't want the flow to be so simplistic as tabindex allows.

I'd be very interested to see what you build if you are able to share the outcome.

Allan