How can I make all table cells tabindex="0" (keyboard accessible)

holdencreative

Hi DataTables folks,

I've been working with DT for some time and love using it. However, I'm bumping up against an accessibility requirement now and haven't had much lucky following previous posts in the forum, re: keyboard accessibility for table cells.

What I've seen is something like this:

  <script>"fnDrawCallback": function () {
      $('.dataTables_scrollBody td').each(function () {
          $(this).attr('tabindex', 0);
      });
  }</script>

But it doesn't seem to work on implementation. Any suggestions?

Thanks,
Andrew H.

allan

What will a cell do on focus? Have you taken a look at KeyTable?

Allan

holdencreative

Hi Allan,

Thanks!

Edited post - Looks like I spoke too soon, the KeyTable plugin does have support for scroll-x and scroll-y.

That said, a simple config in the core to tabindex = all , would be awesome for accessibility (useful for stuff like screen shares and data analysis, etc, too.) Ultimately my hope is to also develop a "copy" event that's not based on Flash (as I believe tabletools is).

Thanks, - Andrew H.

allan

That said, a simple config in the core to tabindex = all , would be awesome for accessibility

Actually, I disagree on this point. Unless focusing on the cells is used for something (inline editing perhaps?) then there is no benefit to being able to focus on cells, and in fact it would just increase the amount of time it takes to navigate through the site since you would need to tab all the way through the table to get to the next item on the page.

If there is an action to be taken on each cell, then KeyTable is available to add this behaviour to the table. It isn't likely to be integrated into the core software, although KeyTable is going to see a big rewrite in the next few months :-)

Allan

holdencreative

Hi Allan,

I can appreciate the actionable context consideration for sure - good point. At the same time, there are cases where the data being read-out itself, is the key thing. Example: finding the last name of an employee.

It sounds like what I'm really asking for is a modular config; I can understand why you would want to avoid that.

Thanks for the note on KeyTable - that's really good to know! I'll keep an eye out for the update :)

allan

Modular is good - that's the whole point of keeping KeyTable separate and out of the core, but still having it available. I see it as a really important aspect of the DataTables suite (even if in its current state it appears a little unloved... :-) ).

Shouldn't screen-readers (assuming that is what you are targeting with this use case?) correctly read out table information. In my experience of working with accessibility for DataTables they have been quite good at reading tabular information.

Regards,
Allan

holdencreative

Hi Allan,

I've been using ChromeVox and a couple of other test methods here - I hear normally tabindexed items spoken - however normal cells aren't tab-focused so they aren't read out. You've probably done more accessibility / compliance testing than I have at this point in my project so I will defer to your experience.

Aside: Did you happen to see the Flexbox / CSS post I put on the forum? It is working really well for me here (and call support fallbacks to a fixed height as well, of course). I imagine you could merge both cases eventually.

allan

You've probably done more accessibility / compliance testing than I have at this point in my project so I will defer to your experience.

I wish I had more experience. I've been reading out to the accessibility community whenever possible and all feedback is welcome! It is quite difficult to develop for something when you don't use it yourself...!

Aside: Did you happen to see the Flexbox / CSS post I put on the forum?

I missed that one - I'll take a gander just now :-)

Allan

rcremona

I've been reading out to the accessibility community whenever possible and all feedback is welcome! It is quite difficult to develop for something when you don't use it yourself...!

Hi Allan! I'm not an expert, but I'd really love to help! We love DataTables and use them extensively, and I can share the accessibility tweaks we've been adding. (Much of my current sprint is actually devoted to UX/a11y in one of our web apps that uses DataTables!)

For instance, on table.draw(), keyboard focus resets. Depending on which event triggered the redraw (did a user activate the ordering control in a column? did a user active a paging control?), browsers can sometimes figure out where to put the focus...but not always. When the browser can't figure it out, the keyboard focus defaults to the <body> tag... which means that after paging, keyboard users and screenreader users have to navigate through the whole page again to get back to the table. With a little tweaking, I set ours up so that, on table.draw(), keyboard focus either remains on the control that triggered the draw, or moves to the caption of the table (which has been updated to tell the user how the table has changed).

We're also working on making the details-control accessible to keyboard users, some tweaks to the paging controls, and some additional ARIA tagging. Fun stuff!

Thanks again for your excellent plugin.

Rebecca

holdencreative

Hey Rebecca,

That's awesome. Aside: Wondering if you can point me to a good resource / method for handling keyboard focus changes on modals?

re: Related thread

• Still working on a legacy-browser compliant responsive/flexbox CSS for DataTables, but it is forthcoming!

rcremona

Hi Andrew,

Any chance you are using Bootstrap? Paypal's Bootstrap Accessibility plugin takes care of exactly that!
https://github.com/paypal/bootstrap-accessibility-plugin#modal-dialog

If you are "rolling your own" modal, I'd try to model my code on theirs.

Hope this helps!
Rebecca

holdencreative

Thanks Rebecca,

Using Foundation 4A in this case - but I'll look into it for sure!

rcremona

Great! Their approach is quite thorough. But, if that turns out to be too complicated, this will at least get you moving in the right direction: https://webaccessibility.withgoogle.com/unit?unit=6&lesson=12

Best,
Rebecca

allan

Hi Rebecca,

Are you able to share an example, or some of your code, for the changes / improvements that you have made?

Thanks,
Allan

rcremona

Hi Allan,

I'd be delighted to. Next week, when things have settled down a bit with the app I'm working on, I'll make everything available on Github, and will put up a sample instance so you can see it running. I'll include some text that calls out the accessibility features. Sorry not to have anything up publicly to show you today!

Here's a quick example, to handle keyboard focus on table draw. We use this technique to create a namespace for our app. Then, in the events that trigger a draw ( for instance, on('page.dt...), or within the column filter code (e.g., after line 15 in your example), we set 〈Namespace〉.focus = $("#element_that_should_get_focus"). Then, we add to the table's draw callback a quick check to see if 〈Namespace〉.focus is set. If yes, we set the keyboard focus on that element, and then unset 〈Namespace〉.focus. If not, we let the browser's default behavior kick in. So, nothing too fancy there!

More soon! The API is making this project a lot of fun (thanks!)

~Rebecca