[Tabs] Implement arrow keyboard

[tuukkao]

Problem description

The Tabs component doesn't implement keyboard support as specified by the WAI-ARIA 1.1 authoring practices. Ideally it would be best if this was implemented in the actual component, since this is standardized behaviour which should be available out of the box with no extra effort from the developer.

Link to minimal working code that reproduces the issue

https://github.com/callemall/material-ui/blob/next/docs/src/pages/component-demos/tabs/BasicTabs.js

Versions

• Material-UI: 352ca60
• React: 15.5.4
• Browser: Firefox 53.0.3, Chrome 58.0.3029.110

[oliviertassinari]

Yes, indeed. I'm closing this issue in favor of #4795. Good point.

[oliviertassinari]

This comment is relevant too #5604 (comment).

[nikzb]

Is anybody currently working on this issue? The lack of keyboard navigation between tabs via the left and right arrow keys is a deal breaker for what I need. If nobody else is working on it, I would be interested in potentially making a PR.

[oliviertassinari]

@nikzb Nobody has been working on it over the last 3 years. Notice that Bootstrap doesn't support it either. You are free to go :).

[mbrookes]

@nikzb I started to look at it a couple of days ago, but got distracted by other things. If you're happy to work on it, I can finish up improving the ARIA story, and together it should be in much better shape for accessibility.

Regarding the keyboard controls: I believe that when a tab is selected by arrow key, the tab key should then select the content, to allow a screen reader to read it.

The W3 spec also recommends that the arrow keys should cause the tab content to change, rather than requiring selection with the space / enter key.

Home and End keys should select the first and last tab respectively. We don't need to support delete.

I have been following this example: https://www.w3.org/TR/wai-aria-practices/examples/tabs/tabs-1/tabs.html

[nikzb]

The W3 spec also recommends that the arrow keys should cause the tab content to change, rather than requiring selection with the space / enter key.

@mbrookes Letting the user activate manually seems like the safer default, rather than having the automatic activation, based on what is stated here: https://www.w3.org/TR/wai-aria-practices/#kbd_selection_follows_focus

Would it make sense to have manual be the default and possibly provide a way to opt-in to automatic activation?

[mbrookes]

based on what is stated here: w3.org/TR/wai-aria-practices/#kbd_selection_follows_focus

That seems consistent with the advice in the other sections. It's saying that if a network request for tabpanel content prevents quickly navigating the tabs, the tabs should require manual activation (i.e. don't automatically activate the tab if doing so blocks navigating to other tabs while the content is loading).

Correct me if I am wrong, but this seems like an implementation issue. Done right, there's no reason that loading data should block navigation.

Yes, you could have a "tabPanelDataLoadedSynchronouslyDontTryToRenderItUnlessTheUserAsksTo" option ;), but I believe it would only serve to encourage the problem.

I suspect that element of the spec was written in earlier times before the availability of async / await.

[nikzb]

The current behavior when you use the "Tab" key to navigate the tabs is not to activate automatically, but instead let the user activate manually if they want to actually view the content for that tab. Since the automatic vs manual activation issue is a grey area, I think it might make sense to stick with the manual activation, even once the navigation is done with arrow keys rather than the tab key.

[oliviertassinari]

I haven't read the discussion in detail. I believe that we should:

• Have a single tab item tabbable. So Tab shouldn't navigate between the tabs like we have today.
• Have the ArrowLeft and ArrowRight move the focus and trigger the change event. It's an automatic activation. However, we can add a reason second argument like we do with the snackbar. So developers can choose to ignore the change events coming from the arrow interaction.

It's what JQuery UI or Reach UI or WCAG are doing.

[devarsh]

Just posting it here for reference : https://reacttraining.com/blog/reach-tabs/

[oliviertassinari]

We are exploring a broader solution in #15597.

[eps1lon]

#20781 was not intended to close this.